contrib updates (was Re: [Cooker] Updated heartbeat, and request)
On Wed, 19 Nov 2003 14:44:52 +0200 Buchan Milne [EMAIL PROTECTED] wrote: Once I have a clean 9.2 installation, or klama's got a 9.2 chroot, I will build packages for 9.2. But, then we need to have a policy for updates to contrib ... and possibly one on per-release release suffixes or epochs too ... I really forgot about previous discussions about updates for contrib, and what ideas were put up and burned down. Isn't the most simple approach to use Mandrake-devel/unsupported/9.2 for this? If there's a way to upload packages for this directory, and have a hdlist generated there, then we can advertise it as a place to get unsupported updates. Since klama gets a chroot for 9.2, an upload script can be put in place to upload there, right? In MandrakeSoft's interest the best place is MandrakeClub, but I don't think it's a good solution for this. I tried getting an upload account there, but after three weeks I still don't have it. And I don't think the reason is that my packaging sucks, or I requested it in a rude way... So for now I just made my updates/backports available in an own repository. But if every contributor starts doing this, then it will still be a mess, so there needs to be a unified solution. -- Marcel Pol
Re: [Cooker] [proposal] contrib process enhancement
On Wed, 19 Nov 2003 15:06:30 +0100 Guillaume Rousse [EMAIL PROTECTED] wrote: OK, now that i have some free time to tr^H^Hdiscuss, here are some thought about how to make contributions easier and better. I propose to discuss here, and set up some page on the wiki when a consensus could be reached. 1) gpg signature of the contrib Currently, contrib package are not signed, or are individually signed by contribuer, making urmi yells every time you install them. I'd like to have them signed, and preferentially with a unique and official mdksoft key, instead of individual contributers keys. The reason if first they are official mdk packages first, it's easier to manage second (i don't want to add a new key to rpm database each time a new contributer arrive) Agreed. 2) unique urpmi database on klama Currently, each time a package has some dependance to build, we have to first check if this dependance is either a contrib or a main package. This is both ugly and unpractical. I want to be able to install foo-devel with a single command, and let the system find where to fetch this package from I always use sudo ue -u foo-devel, and it installs the package from main or from contrib. It wasn't always like this, but it works that way for a while. 3) access to incoming Only Lenny is able to retrieve SRPM uploaded on ftp.mandrakesoft.com, so we generally ask people to also provide a link to retrieve it from elsewhere. All contributers should be able to access incoming, whatever location it is. Why not make people upload directly on klama ? Yes, please. Not everybody can also make their package available on their own webspace. 4) better mail adresses Each contributer should have some kind of official mandrake-linux mail adress, and be able to change real adress it correspond to easily. As a contributer is someone with a shell account on klama, why not use a SMTP there, delivering mail locally, making each one able to redirect mail to where he wants with a simple .forward ? I don't care about control over the .forward, but it seems easier for Lenny this way. I cannot imagine that he likes to get bothered weekly about a changed mailadress. So making ths configurable by the user makes it a win-win situation. 5) better mailing lists Do we really need two mailing-lists (maintainer and compil) ? Could thoses lists get subscribers only,so as to avoid spam ? Could subscription to those mailing list becomes automated (one shell account - one mail adress - one subscription) Is there a compil mailinglist? I didn't know. Does it generate traffic? 6) anything else ? I just posted this in another thread, but this thread seems better. 6) updates for stable releases I really forgot about previous discussions about updates for contrib, and what ideas were put up and burned down. Isn't the most simple approach to use Mandrake-devel/unsupported/9.2 for this? If there's a way to upload packages for this directory, and have a hdlist generated there, then we can advertise it as a place to get unsupported updates. Since klama gets a chroot for 9.2, an upload script can be put in place to upload there, right? In MandrakeSoft's interest the best place is MandrakeClub, but I don't think it's a good solution for this. I tried getting an upload account there, but after three weeks I still don't have it. And I don't think the reason is that my packaging sucks, or I requested it in a rude way... So for now I just made my updates/backports available in an own repository. But if every contributor starts doing this, then it will still be a mess, so there needs to be a unified solution. -- Marcel Pol
Re: [Cooker] Re: none
On Tue, 18 Nov 2003 14:21:40 +0100 Frederic Crozat [EMAIL PROTECTED] wrote: On Tue, 18 Nov 2003 10:57:40 +0100, Frederic Lepied wrote: Guillaume Rousse [EMAIL PROTECTED] writes: [EMAIL PROTECTED] guillomovitch]$ rpm -qlp rpm/RPMS/i586/gkrellm-2.1.21-1mdk.i586.rpm | grep /usr/lib /usr/lib/gkrellm2 /usr/lib/gkrellm2/plugins /usr/lib/menu/gkrellm BTW, why is /usr/lib/menu not /usr/share/menu ? It was for compatibility with debian. Not only : apps can be arch dependent and since /usr could be shared by NFS, menu entries should be in /usr/lib.. (well, it was Debian rationale for menu location..) But the menufiles are arch-independent. I assume it will be fixed when we switch to the freedesktop menufiles proposal. It doesn't list the place for these files however, but it seems a lot like the kde/gnome desktop files that are in /usr/share/app*. -- Marcel Pol
Re: [Cooker] Re: none
On Tue, 18 Nov 2003 16:32:26 +0100 Götz Waschk [EMAIL PROTECTED] wrote: Am Dienstag, 18. November 2003, 16:27:37 Uhr MET, schrieb Marcel Pol: apps can be arch dependent and since /usr could be shared by NFS, menu entries should be in /usr/lib.. (well, it was Debian rationale for menu location..) But the menufiles are arch-independent. The menu files are arch-independant, but the application in the menu entry can be architecture-dependant. Imagine a menu entry for vmware, that wouldn't make sense on the Linux/PPC machine. True, but I would call that an exception. Most apps in the menu are available on different architectures. That doesn't count for the libraryfiles of them, .so files are all arch dependent. The menufile can still be used on Linux/PPC, it can still generate a menu, nothing will crash, while you cannot load a .so file for x86 on ppc. The menufile will be useless though, because there's no package that comes with it. I assume it will be fixed when we switch to the freedesktop menufiles proposal. It doesn't list the place for these files however, but it seems a lot like the kde/gnome desktop files that are in /usr/share/app*. So the architecture-dependance of the menu files will be lost? They use a different approach. http://freedesktop.org/Standards/desktop-entry-spec/desktop-entry-spec-0.9.4.html There is a key TryExec: A list of regular expressions to match against for a file manager to determine if this entry's icon should be displayed. Usually simply the name of the main executable and friends. So if vmware is not installed on Linux/PPC, it will not be part of the menu. -- Marcel Pol
Re: [Cooker] libtool problem while using %configure in kde rpm
On Tue, 18 Nov 2003 22:22:36 + Nick Brown [EMAIL PROTECTED] wrote: Hi, I'm working on my second rpm for submission to mandrake contrib but I've encountered a problem. I'm trying to create a spec file for kscope 0.4 I've followed the standard .spec given in the wiki and have this snippet in my file; %prep %setup %build %configure %make %install rm -rf %buildroot %makeinstall On top of your specfile, you can define this: %define __libtoolize/bin/true The libtoolize macro is part of the %configure macro (check with rpm --eval %configure), and because there's a version mismatch, things break. Mandrake uses libtool-1.4, while kde uses libtool-1.5 (or 1.4a?). Version 1.4 doesn't understand `--tag=CXX', so it breaks. When you add this define, libtoolize won't be run, and all should go well. However I get the following error message while trying to build the package; c++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/lib/qt3//include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -O2 -O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro -fno-exceptions -fno-check-new -c kscope_meta_unload.cpp/bin/sh ../libtool --mode=link --tag=CXX c++ -O2 -O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro -fno-exceptions -fno-check-new -o kscope -L/usr/X11R6/lib -L/usr/lib/qt3//lib -L/usr/lib -R /usr/lib -R /usr/lib/qt3//lib -R /usr/X11R6/lib projectfilesdlg.o progressdlg.o kscopepixmaps.o calltreedlg.o scanprogressdlg.o dirscanner.o kscopeconfig.o preffrontend.o prefcolor.o preferencesdlg.o openprojectdlg.o newprojectdlg.o ctagslist.o ctagsfrontend.o frontend.o querypage.o querywidget.o cscopefrontend.o searchlist.o editorpage.o editormanager.o filelist.o projectmanager.o editortabs.o kscope.o main.o projectfileslayout.o calltreelayout.o scanprogresslayout.o prefcolorlayout.o preffrontendlayout.o openprojectlayout.o newprojectlayout.o preffrontend.moc.o frontend.moc.o prefcolor.moc.o querypage.moc.o projectmanager.moc.o calltreedlg.moc.o newprojectdlg.moc.o progressdlg.moc.o kscopeconfig.moc.o searchlist.moc.o editorpage.moc.o kscope.moc.o filelist.moc.o ctagsfrontend.moc.o scanprogressdlg.moc.o projectfilesdlg.moc.o querywidget.moc.o cscopefrontend.moc.o editormanager.moc.o editortabs.moc.o openprojectdlg.moc.o preferencesdlg.moc.o ctagslist.moc.o kscope_meta_unload.o -lktexteditor -lkparts -lkdeui -lkdecore -lqt-mt -lpng -lz -lm -lXext -lX11 -lresolv -lSM -lICE -lpthread -lresolv libtool: unrecognized option `--tag=CXX' Try `libtool --help' for more information. make[2]: *** [kscope] Error 1 make[2]: Leaving directory `/home/nick/rpm/BUILD/kscope-0.4/kscope' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/nick/rpm/BUILD/kscope-0.4' make: *** [all-recursive-am] Error 2 error: Bad exit status from /home/nick/rpm/tmp/rpm-tmp.99463 (%build) RPM build errors: Bad exit status from /home/nick/rpm/tmp/rpm-tmp.99463 (%build) The problem would appear to be caused by the fact that Mandrake ships with libtool 1.4.3 and kscope (and it would appear most kde packages) uses libtool 1.4a [EMAIL PROTECTED] nick]$ cd rpm/BUILD/kscope-0.4/admin/ [EMAIL PROTECTED] admin]$ ./ltconfig --version ltconfig (GNU libtool) 1.4a (1.641.2.206mm 2001/04/03 21:47:47) This would appear to mean that I cannot use %configure in my .spec file. Are there plans to upgrade mandrakes libtool to version 1.4a? How have others addressed this problem? And is there a standard Mandrake replacement for %configure in kde packages? -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] xfce4-4.0.0-1mdk
On Sun, 16 Nov 2003 02:58:19 +0100 andre [EMAIL PROTECTED] wrote: On Thursday 13 November 2003 15:42, Marcel Pol wrote: On Thu, 13 Nov 2003 11:01:31 +0100 Torstein Dybdahl [EMAIL PROTECTED] wrote: It would be nice to have xfce4 added to the displaymanager choices. The session script is already there, but it doesn't get configured from the%postinstall script. There are more small things like this that needs to be done. When you run /usr/sbin/fndSession, does it get listed in your dm? could you change /etc/X11/wmsession.d/10XFce4 to a higher number. Xtart wont work with otherwise. I would suggest to change it to 40 to get /etc/X11/wmsession.d/40XFce4 I just changed it to 06XFce4 in xfwm-4.0.1-1mdk, to have the same number as XFce (3), which it should replace. Why is it a problem, is it because there is already a session file with the same number? Fvwm provides a /etc/X11/wmsession.d/10Fvwm1 Or is there another reason? If it's broken, I'm willing to fix it, but if Xtart is broken, why should I fix xfce? Can you provide more information? Also, could people test the session script? I have local problems with login, and have a hard time testing this feature. If someone can confirm that it works on gdm/xdm/kdm/mdkkdm, that would be great. -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] xfce4-4.0.0-1mdk
On Sun, 16 Nov 2003 02:58:19 +0100 andre [EMAIL PROTECTED] wrote: could you change /etc/X11/wmsession.d/10XFce4 to a higher number. Xtart wont work with otherwise. I would suggest to change it to 40 to get /etc/X11/wmsession.d/40XFce4 [resend through another smtp] I just changed it to 06XFce4 in xfwm-4.0.1-1mdk, to have the same number as XFce (3), which it should replace. Why is it a problem, is it because there is already a session file with the same number? Fvwm provides a /etc/X11/wmsession.d/10Fvwm1 Or is there another reason? If it's broken, I'm willing to fix it, but if Xtart is broken, why should I fix xfce? Can you provide more information? Also, could people test the session script? I have local problems with login, and have a hard time testing this feature. If someone can confirm that it works on gdm/xdm/kdm/mdkkdm, that would be great. -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] xfce4-4.0.0-1mdk
On Sun, 16 Nov 2003 07:09:03 + Tim Sawchuck [EMAIL PROTECTED] wrote: Also, could people test the session script? I have local problems with login, and have a hard time testing this feature. If someone can confirm that it works on gdm/xdm/kdm/mdkkdm, that would be great. Yes, I ran fndSessionand it shows up in GDM; I have no KDE rpms at all, and just the minimum gnome libs to run GDM, Gedit, and GnuCash. XFCE4, FluxBox and IceWM are installed. Ok, thank you. -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] xfce-utils-4.0.1-1mdk
On Sun, 16 Nov 2003 16:50:46 +0100 andre [EMAIL PROTECTED] wrote: On Sunday 16 November 2003 14:55, Marcel Pol wrote: - 4.0.1 - sysconfdir = /etc/X11 - use 06 as session numbering - postinstall: run fndSession - don't install gdm sessionfile Xtart has a problem when two wm have the same sessionnumber Ok, thanks for the information. So when you just have XFce4, and not XFce (3), it should work fine, right? XFce4 should replace XFce (3), so it's just a temporary cooker thing, it should be unique by the time 10.0 gets released. And I assume that when it was numbered 10, you also had fvwm installed? It's the only one that also uses 10. -- Marcel Pol
Re: [Cooker] xffm (was:Re: [Contrib-Rpm] xfce4-4.0.0-1mdk)
On Fri, 14 Nov 2003 09:46:08 +0100 Helge Hielscher [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2003 15:42:12 +0100, Marcel Pol wrote: Thanks for packaging one of the best WM's! You're welcome :-) Are you going to package xffm too? Yes, I'm going to, but didn't get around to it yet. -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] xfce4-4.0.0-1mdk
On Thu, 13 Nov 2003 11:01:31 +0100 Torstein Dybdahl [EMAIL PROTECTED] wrote: It would be nice to have xfce4 added to the displaymanager choices. The session script is already there, but it doesn't get configured from the %postinstall script. There are more small things like this that needs to be done. When you run /usr/sbin/fndSession, does it get listed in your dm? Thanks for packaging one of the best WM's! You're welcome :-) -- Marcel Pol
Re: [Cooker] iptables nat not working in 9.2
On Thu, 13 Nov 2003 12:50:30 +1100 [EMAIL PROTECTED] wrote: Hello I recently discovered that iptables 1.2.8 nat command does not work fully in 9.2 on i586 Something like this: iptables -t nat -A PREROUTING -i eth0 -d xx.xx.xx.xx -p tcp -m tcp --dport 23 -j DNAT --to-destination yy.yy.yy.yy:23 wont work with invalid error message. I made this command up but the exact command is not important, but DNAT to a different destination and even just REDIRECT to a different port is giving the invalid error message. It's because the mandrake kernel uses patches from patch-o-matic. In 9.1 this didn't give problems, but in 9.2 it apparently did (hum, it was even a netfilter faq). It was reported as a bug here: http://qa.mandrakesoft.com/show_bug.cgi?id=5454 The bugreport has links to rpms which are built on a vanilla kernel-source, and they should work on 2.4-vanilla and 2.6. This problem was first reported for just not working with 2.6, and therefore the solution was to make a iptables_kernel-2.6 package in contribs. This one should work on 2.4-vanilla as well. Should this be made into an Errata? What do people think? And there should come a package like iptables_vanilla, which has been built against a vanilla kernel-source. How should it be done, as an extra source package, or should it be built from the normal iptables package, where it has 2 buildprocesses, once against a mandrake kernel, and once against a vanilla kernel? What do you think Juan? If you don't reply I guess we should make a contrib package iptables_vanilla which is being kept in sync with the iptables package in main. -- Marcel Pol
Re: [Cooker] u2fs?
On Wed, 12 Nov 2003 13:08:39 +0100 Oden Eriksson [EMAIL PROTECTED] wrote: How do I mount FreeBSD UFS2 partitions under Mandrake? I used: mount -t ufs -o ufstype=44bsd /dev/hda8 /mnt Hope this helps. -- Marcel Pol
Re: [Cooker] test9.4mdk with ext3 as module
On Wed, 05 Nov 2003 23:10:25 + Michael Lothian [EMAIL PROTECTED] wrote: I've just downloaded the SRPM of test9 4mdk however when I try and recompile for my athlon I get the following error [EMAIL PROTECTED] fireburn]$ rpm --rebuild --target athlon kernel-2.6-2.6.0-0.test9.4mdk.src.rpm Installing kernel-2.6-2.6.0-0.test9.4mdk.src.rpm warning: user blino does not exist - using root warning: group blino does not exist - using root warning: user blino does not exist - using root warning: group blino does not exist - using root warning: user blino does not exist - using root warning: group blino does not exist - using root warning: user blino does not exist - using root warning: group blino does not exist - using root Building target platforms: athlon Building for target athlon error: Architecture is not included: athlon The only configfiles included are for i586 and ppc, like: kernel-config-2.6-i586 The easiest way to get an athlon optimised kernel is to install the kernel-source rpm of 2.6, and build a custom kernel for athlon. Or you could make a kernel-config-2.6-athlon and ask blino to include it in the src.rpm. -- Marcel Pol
Re: [Cooker] Re: Versioning for multiple releases: a modest suggestion
On Fri, 7 Nov 2003 00:20:11 +0100 (CET) Christiaan Welvaart [EMAIL PROTECTED] wrote: On Fri, 7 Nov 2003 01:09, Buchan Milne wrote: snip epoch stuff If one mixes packages from various releases, and something does not work, the dependencies are not correct. Epoch should not be used to fix binary incompatibilities. Example: to allow upgrading downgrading mozilla/galeon/etc., all moz libraries that are used by other packages must be in a separate package, and have a major version number. If binary incompatible compiler versions must be taken into account, the compiler version must be added as well. So instead of libxpcom.so in package mozilla, you have libxpcom-1.4-3.3.so.0.0 in package libmozilla1.4_3.3-1.4-2mdk (libxpcom of mozilla 1.4 compiled with g++ 3.3, binary incompatible with libxpcom-1.4-3.1.so.0.0 and libxpcom-1.3-3.3.so.0.0) (the exact placement of the library versions may be different, I don't know what's best) Then it is possible to have mozilla 1.5 installed, together with a galeon that requires mozilla 1.3. Upgrading a mdk 9.1 with these packages to mdk 9.2 does not upgrade mozilla, but does upgrade galeon, and everything still works. Maybe it works in this case ( I don't know if it does), but it's definitely not guaranteed to work in all situations. It's not just gcc that breaks binary compatibility, it's also other libraries, or libraries used by libraries. Remember the nightmare when going from libpng2 to libpng3? Sometimes compatibility even breaks without the library changing its soname...sometimes glibc breaks binary compatibility...sometimes this, sometimes that... Sometimes you know these things before you run into them, and sometimes not. But having to set dependencies for this makes things too hard to maintain. Who is gonna test it, and who is gonna set all these dependencies? Up to now the resolution was to advise to not mix packages from different releases, because sometimes things work, and sometimes things break in weird ways. I think we should stick to that, I wouldn't dare to advise to trust on dependencies, whatever the amount of time that's being put in testing and setting it all up. Mixing packages is Russian roulette, and should be advertised as such. When people choose to do that, we won't stop them. But when things break because a 9.1 medium (texstar's kde for 9.1) has newer versions then a new mdk release, then an Epoch can fix that. That's a goal that we can make. The goal you have seems unrealistic to me. I just wish it was possible, but I don't see it happening. -- Marcel Pol
[Cooker] Re: [Contrib-Rpm] juk-1.95a-1mdk
On Wed, 5 Nov 2003 02:39:30 +0100 (CET) Lenny Cartier [EMAIL PROTECTED] wrote: [Contrib-RPM] Name: juk Relocations: (not relocateable) Version : 1.95a Vendor: MandrakeSoft Release : 1mdk Build Date: Tue Nov 4 21:22:21 2003 This package is part of kdemultimedia since 3.1.93, so it's not needed for cooker. -- Marcel Pol
Re: [Cooker] Re: [CHRPM] kdebase-3.1.3-80mdk (many undefined symbols)
On Mon, 27 Oct 2003 14:00:34 +0100 arakeis [EMAIL PROTECTED] wrote: Laurent Montel wrote: Bad solution, because all other packages was compiled with qt-3.1. I created and upload a new kdebase-3.1.3-81mdk which fixed compiled problem, but there is a problem with upload :( For people who missed kde very much and went on installing the qt3.2 from your personal area, the right thing to do now would be ??? removing qt3.2, intalling qt3.1 and the -81mdk version of kdebase ? but 3 days after your post, it doesn't show up on the mirrors... (tried ciril.fr and proxad/free.fr) You could install qt3.1 and kde-3.1.3-79mdk from 9.2, and wait for 81mdk for upgrade. Or you could install the qt3.2 and kde3.2 packages from lmontels homepage and wait till these (or newer) are uploaded in cooker. -- Marcel Pol
Re: [Cooker] Re: LG Drives
On Sun, 26 Oct 2003 01:20:35 +0200 Juan Quintela [EMAIL PROTECTED] wrote: marc == Marc Guise [EMAIL PROTECTED] writes: marc I read the post about Mdk 9.2 and LG on mandrakeusers.org. I have cd-rw drive, marc model HL-DT-ST GCE 8400b and I have Mdk 9.2rc2 running. There are no problems marc with my LG drive 21mdk just updated (vdanen should be doing the official update) fixes that problem. Only LG plain CD-ROMS are affected. Later, Juan. PD. Yep, whoeved decided at LG that reusing for UPLOAD_FIRMAWARE command FLUSH_CACHE comand should be shoot. Twice. While reading slashdot, I found this comment interesting (yes, that does happen on slashdot :-) ) http://slashdot.org/comments.pl?sid=83579cid=7310813 Why is Linux trying to send a flush cache command to a CD-ROM drive in the first place? That's a stupid thing to do. The ATAPI FLUSH CACHE command tells the device to flush its write cache to the media. A CD-ROM has no write cache, and can't write to any media. Of course, it's even more stupid for a drive to self-destruct when it gets a flush cache command... Is this maybe 2 bugs working together? Using FLUSH_CACHE where it shouldn't, and have the cdrom reading that as UPLOAD_FIRMWARE -- Marcel Pol
Re: [Cooker] OT: stupid rpm Q ( requires xx || yy )
On Wed, 22 Oct 2003 23:37:11 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: Hi, i'm trying to update firestarter in order to use it under 2.6 test kernels, the original src.rpm requires iptables and we have two packages for iptables one for 2.4 kernel one for 2.6 kernel I think the reason that the iptables package in main doesn't work on 2.6 is the same as the reason it doesn't work on 2.4.22 vanilla in bug: http://qa.mandrakesoft.com/show_bug.cgi?id=5454 So essentially the contrib package shouldn't be needed. I tried with iptables-1.2.9-rc1. Compiled against 2.4.22-18mdk, it doesn't work in 2.6.0-test8, while when it is compiled against vanilla 2.4.22, 2.4.23-pre1 or 2.4.23-pre7, SNAT/POSTROUTING works ok for me. The Mandrake kernel is based on 2.4.23-pre1, so something is wrong in the mandrake kernel then. To be clear, I didn't test more rules, and I didn't test it on one of the vanilla 2.4 kernels, but I blindly assume the behaviour is the same. If you're upgrading firestarter for mdk 10.0, then the priority should be on fixing this kernel bug. But it shouldn't hurt to use the virtual provides as a requires, it's probably a good thing. -- Marcel Pol
Re: [Cooker] usb webcam in mandrake 9.2
On Wed, 22 Oct 2003 11:51:06 + Thierry Vignaud [EMAIL PROTECTED] wrote: Guy McArthur [EMAIL PROTECTED] writes: I had to add the line above ov511 ovcamchip to /etc/modules.conf for my Creative USB webcam (I think it uses the same usb chip as your Phillips). This is because the kernel module was renamed (search for 'Linux ov511' to find the driver site). what was the old driver name ? (so that i can alter proper files) I'm not the parent poster, but the old name for ovcamchip is ovsensor. -- Marcel Pol
Re: [Cooker] k3b_010cvs icon does not appear in the KDE menu
On Mon, 06 Oct 2003 14:59:36 +0100 Eric Fernandez [EMAIL PROTECTED] wrote: I don't get the icons in the KDE menu with k3b_010cvs (but k3b in main has got icons). The icons are in the package though. Is that specific to my install ? It works here in my kde menu. The only difference with the menufile from 0.9 is that in the .desktop file, the second Terminal is set to false instead of 0 When you run update-menus -v, does it appear? And when you replace the /usr/lib/menu/k3b file with the one from 0.9, and run update-menus, does it appear then? What does your ~/.kde/share/applnk-mdk/Applications/Archiving/Cd burning/k3b.desktop look like? -- Marcel Pol
Re: [Cooker] Re: k3b_010cvs icon does not appear in the KDE menu
On Tue, 7 Oct 2003 14:58:10 +0200 Mark Draheim [EMAIL PROTECTED] wrote: it's the menu file ?package(k3b) ^^^ change that to k3b_0.10cvs Ah, of course. I see it now. Thanks, I'll fix it. -- Marcel Pol
Re: [Cooker] XFce4
On Sat, 4 Oct 2003 12:17:54 -0400 Greg Meyer [EMAIL PROTECTED] wrote: Is anyone planning on building XFce4 for contrib? It could just replace xfce in main I'd say, as long as the maintainer accepts those packages. I'm not yet planning on making them though. -- Marcel Pol
Re: [Cooker] XFce4
On Sat, 4 Oct 2003 15:26:52 -0400 Philip Webb [EMAIL PROTECTED] wrote: 031004 Marcel Pol wrote: On Sat, 4 Oct 2003 12:17:54 -0400 Greg Meyer [EMAIL PROTECTED] wrote: Is anyone planning on building XFce4 for contrib? It could just replace xfce in main I'd say, as long as the maintainer accepts those packages. I'm not yet planning on making them though. XFCE4 has been exhaustively tested before release sb one of the most solid applications in the Mdk list. it's a whole new version of the best desktop manager around. it sb included in main ASAP: any chance of squeezing it into 9.2 ? The iso's for 9.2 are already made, so it's not possible to squeeze it in 9.2. It was requested some weeks ago, but it was already in rc-time, and too late, or in beta-time, and nobody got around packaging a XFce pre or rc. I forgot when exactly. There are only so many people packaging software There's no point in asking for it now for cooker/9.2, cooker will switch to 9.3/10 development. The same for OpenOffice.org. And updates is for security/bugfix updates, not version upgrades, just because of it. That's what Club is for. XFCE shd become Mdk default, replacing KDE in Mdk 10.0 . Ehh, Kde has been Mandrake's default forever, imo I don't think there's much point in discussing this, sorry. -- Marcel Pol
Re: [Cooker] Re: contribs, Was: Replacing proftpd by pureftpd
On Thu, 2 Oct 2003 06:01:39 -0400 Austin [EMAIL PROTECTED] wrote: On 10/02/2003 01:52:33 AM, Vincent Danen wrote: On Wed Oct 01, 2003 at 04:33:08PM -0400, Austin wrote: You are all missing the easiest solution: --- unite contib and main --- No way in hell... not the way things currently stand. The only drawbacks would be: - more security updates (this could lead to safer distro though, ditch the unsafe apps altogether) Really? Some of those things are in contribs for precisely that reason... people need/want the apps but we've recognized them as being unsafe(ish). Which would involve more QA, more testing, more post-release support, more developers paying attention to what's in contribs, and just plain old more of everything. Which would not be a problem if we had fewer packges AND more help, right? Both of these things are possible in the future. The more packages we provide, the more room for error, the more bugs, the more post-release support, the more QA, the more testing, the more validation... can I say more more more? =) More support, more QA, more testing, and more validation sounds like a GOOD thing to me... But who is gonna do it? At the moment Vincent is doing updates for stable releases. Doubling the packages with packages from contrib will double the number of packages, but quadruple the work, or even worse. Who is gonna do that if it's not Vincent? -- Marcel Pol
Re: [Cooker] Re: Re: And next ?
On Tue, 30 Sep 2003 18:06:57 -0400 David Walser [EMAIL PROTECTED] wrote: Marcel Pol wrote: On Tue, 30 Sep 2003 06:07:50 -0400 David Walser [EMAIL PROTECTED] wrote: Laurent Montel wrote: And splitting a single application (kopete and others) into 3-4 seperate rpms just doesnt make sense. Why ? Do you know libification ? Is it necessary when nothing besides that single app is ever going to use the library? I think yes. On amd-64 the library packages will be named different (libkopete1 vs something like libkopete1-64), and the file locations will be different as well (/usr/lib vs /usr/lib64), so splitting the libraries and binaries (/usr/bin) is a good thing. Why? Is somebody going to want to install 32-bit and 64-bit versions of the kopete library on their machine? Good question, and I'm not informed enough to give a good answer. In my mind it might be easier to just use the architecture in the rpm, like libkopete1-%version-%release.amd64.mdk.rpm, instead of forcing 64 everywhere, but maybe I'm just thinking too simple. I don't know which fundamental problem is being solved with this solution. I just know it's not specific to kde, and if there's a discussion about it, it should be about the fundamental problem/solution. If there's a libpolicy, it should be that all packages follow that policy imo. -- Marcel Pol
Re: [Cooker] Re: And next ?
On Tue, 30 Sep 2003 06:07:50 -0400 David Walser [EMAIL PROTECTED] wrote: Laurent Montel wrote: And splitting a single application (kopete and others) into 3-4 seperate rpms just doesnt make sense. Why ? Do you know libification ? Is it necessary when nothing besides that single app is ever going to use the library? I think yes. On amd-64 the library packages will be named different (libkopete1 vs something like libkopete1-64), and the file locations will be different as well (/usr/lib vs /usr/lib64), so splitting the libraries and binaries (/usr/bin) is a good thing. -- Marcel Pol
Re: [Cooker] And next ?
On Sun, 28 Sep 2003 21:42:05 +0300 Diego Iastrubni [EMAIL PROTECTED] wrote: * patch wine to be able to use mono's winforms Suply the patch and I am sure someone can take a look. the patch is found here: http://openlinksw.com/mono/index.html read also: http://go-mono.com/winforms.html http://www.nullenvoid.com/mono/wiki/index.php/MonoWinePackages What I read on the mailinglist was that it's really not mature and usefull, so I decided to wait a while, and didn't bother with it yet. Also, the wine patch is for an older wine version then the one in Mandrake (last time I looked), I have no clue if it even applies. * mono in mdk out of the box! (if sharp develop will run on mono bring it on baby!) Supply packages/patches, and I am sure someone will take a look. sorry, for this we just need to sit on our ass and wait :( It's in contribs. -- Marcel Pol
Re: [Cooker] k3b : icon missing in the menu ?
On Fri, 26 Sep 2003 11:06:16 +0100 Eric Fernandez [EMAIL PROTECTED] wrote: I use the latest contrib k3b (_010cvs) and the icon is missing in my K menu. Is it a packaging problem or a personal config issue ? Works For Me. /usr/lib/menu/k3b should list k3b.png as icon, which should exist as /usr/share/icons/k3b.png Does running update-menus list it again? -- Marcel Pol
Re: [Cooker] contrib k3b_0.10cvs conflicts with official k3b
On Wed, 24 Sep 2003 08:35:32 +0200 cpjc [EMAIL PROTECTED] wrote: I can't complete my cooker upgrade because urpmi detect a conflict between the k3b_0.10cvs (located in contrib) and the official k3b. Is it possible to merge ? No, it's not really possible to merge them. K3b in main was frozen, and the contrib package provided extra dvd features. I should probably add a conflicts to the specfile, so urpmi will handle it better. [EMAIL PROTECTED] root]# rpm -q k3b k3b-0.9-10mdk [EMAIL PROTECTED] root]# urpmi --auto-select Pour satisfaire les dépendances, les paquetages suivants vont être installés (9 Mo): k3b_0.10cvs-0.10-0.20030918.1mdk.i586 libk3b_0.10cvs1-0.10-0.20030918.1mdk.i586 Est-ce correct ? (O/n) o Ouch, that's not right :-( A contrib package should not replace a package in main automatically. It should probably be fixed by not providing k3b at all. Weird though, when I urpmi k3b, it installs k3b from main, and after that, when I urpmi --auto-select it wants to upgrade to the contrib package. -- Marcel Pol
Re: [Cooker] contrib k3b_0.10cvs conflicts with official k3b
On Wed, 24 Sep 2003 08:29:39 -0400 Charles A Edwards [EMAIL PROTECTED] wrote: On Wed, 24 Sep 2003 13:54:16 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: the main package doesn't know about the existence of the contrib package, but even then lib3b_0.10cvs shouldn't have troubles with libk3b i missed to add provides libk3b in libk3b.0.10cvs No. The k3b-cvs is in contrib and has a higher version than the k3b which is in main and therefore needs to carry a Conflicts: k3b 0.10.0 But as the cvs spec is currently written even that would not help as the cvs-spec carries Obsoletes: kde3-k3b k3b ^^^ Provides: kde3-k3b k3b That was the problem indeed. It should be fixed now. I also added conflicts, since the package names are different, so urpmi should handle a manual upgrade better. I remember that urpmi, with file conflicts, just replaced the installed package with the chosen package, but apparently it doesn't do that. It should now ask to remove the packages in main, if you select k3b from contrib. -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] k3b_0.10cvs-0.10-0.20030918.2mdk
On Wed, 24 Sep 2003 08:50:47 -0400 Charles A Edwards [EMAIL PROTECTED] wrote: On Wed, 24 Sep 2003 14:30:26 +0200 (CEST) Marcel Pol [EMAIL PROTECTED] wrote: +#Obsoletes:kde3-k3b k3b This is still wrong. It should not obsolete k3b or you will still have the same results as before when using urpmi --auto-select, k3b-cvs will try to replace k3b It's a comment now. I could have just deleted the lines, true. But I don't think it's a problem. The package doesn't obsolete/provide this anymore. -- Marcel Pol
[Cooker] Re: [Contrib-Rpm] smokeqt-1.2.1-1mdk
On Wed, 24 Sep 2003 02:30:19 +0200 (CEST) Olivier Blin [EMAIL PROTECTED] wrote: [Contrib-RPM] Name: smokeqt Relocations: (not relocateable) Version : 1.2.1 Vendor: MandrakeSoft Release : 1mdk Build Date: Wed Sep 24 02:18:58 2003 URL : http://perlqt.sf.net/ Summary : SmokeQt binding library for Qt How does this relate to kdebindings-3.1.3? Smoke is part of that, but is that an older version or so? When I tried building it with kdebindings-3.1.2, compilation used a lot of memory, so I just disabled the build of smokeqt. -- Marcel Pol
Re: [Cooker] Sane
On Thu, 18 Sep 2003 14:33:43 +0200 Dave Cotton [EMAIL PROTECTED] wrote: According to the mirrors I've tried sane-backends and libraries are at 1.0.12-3mdk and sane-frontends is at 1.0.11-1mdk, neither kooka nor xsane allow me to scan. Could you file a bugreport on bugzilla? Make sure to have the latest packages in cooker, and tell what hardware you have, and what the output is of sane-find-scanner and scanimage -L. Also, is it a scsi, usb or parport scanner? -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] kernel-multimedia-2.4.22.9mm.1mdk-1-1mdk
On Wed, 17 Sep 2003 14:24:32 +0100 Eric Fernandez [EMAIL PROTECTED] wrote: Adam Williamson wrote: Nope, I meant forked. As in this email from Olivier Blin: I don't understand. What does that mean here (because I don't know haow this matches the usual fork meaning). It means that at the time of the fork, Lenny made a copy of the cooker contrib tree to a 9.2 contrib tree. I assume he will handpick updates from cooker into 9.2 contrib. -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] kernel-multimedia-2.4.22.9mm.1mdk-1-1mdk
On Wed, 17 Sep 2003 16:53:00 +0200 (MEST) [EMAIL PROTECTED] wrote: could you may be then take a look at my dvb-apps src.rpm and eventually push it to contrib (so it eventually could get in MDK-9.2's contrib) Ok, I can upload it for you. I had to change your patch to Makefile.am, to link to ../../include, instead of ../include. And I marked the files in /etc as %config(noreplace), so that when someone edited them, they won't get overwritten when the rpm gets upgraded. That's correct? -- Marcel Pol
Re: [Cooker] dvd burning tools update hack-k3b
On Tue, 16 Sep 2003 15:36:32 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: On Mon, 15 Sep 2003 19:31:28 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: have you installed the plugins packages ? Err, yes, so it's a user error. I was confused by the 2 plugin packages OK, you mean i should put libk3bplugins in the plugin package ? not only the plugins libraries Oh, of course... I'll change it, thanks. by the way what does DAO mean for you ? i'm having a little discussion with one of the authors of k3b, and he says DAO == SAO in everyday language but i always thought that DAO == write a complete disk and then fixate it ( for DVD's if DAO is selected the multi session settings are disabled, for CD active) I had no clue what SAO was, but according to http://www.optorite.com/general_faq.htm#GF_Q1 it's DAO with session support. So that says it like you say it now. i'll inform me later , thanks for the link :) It would make sense to automatically fixate in DAO mode then, and make fixation and multi-session optional in SAO. I don't think it makes things clear if he merges SAO and DAO into one DAO option, if that's what he wants(?). no i was complainig that DVD is normaly not fixated even in DAO mode, and then decided to check what's the situation with CD-R's isn't it actually merged (for CD-R) in my package (ie in 0.10)? i haven't try burning CD with DAO multi session, but it's valid choice if burn is pressed it asks for media Hum, according to man cdrecord, it treats dao and sao the same. In k3b I selected DAO, but there's no way to really select multi-session or fixation. It did fixate though by default. This is the commandline it used: /usr/bin/cdrecord -v gracetime=2 dev=0,0,1 speed=1 -dao -dummy driveropts=burnfree -eject fs=8m -overburn -useinfo -audio /tmp/kde-marcel/k3b_audio_0_01.inf That's what you mean? -- Marcel Pol
Re: [Cooker] dvd burning tools update hack-k3b
On Mon, 15 Sep 2003 07:52:53 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: On Thu, 11 Sep 2003 09:29:11 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: an update for dvd+rw-tools is needed for support of data dvd copy (and making k3b quiet ) http://varna.demon.co.uk/~svetlio/ruby-contrib/mdk-cook/hack-k3b/ as i could't see it @ changelog i changed the name to k3b_0.10cvs and added some spell fixes in the DVD info messeges Thanks. I uploaded it now (didn't get around to it in the weekend). I don't have a dvd burner, so I don't think I can test the functionality that's added. I did have problems with burning mp3 and wav files on a regular cdr, it complained about unknown file type, while k3b 0.9 didn't have problems with that. -- Marcel Pol
Re: [Cooker] dvd burning tools update hack-k3b
On Mon, 15 Sep 2003 16:50:23 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: http://varna.demon.co.uk/~svetlio/ruby-contrib/mdk-cook/hack-k3b/ as i could't see it @ changelog i changed the name to k3b_0.10cvs and added some spell fixes in the DVD info messeges Thanks. I uploaded it now (didn't get around to it in the weekend). I don't have a dvd burner, so I don't think I can test the functionality that's added. I did have problems with burning mp3 and wav files on a regular cdr, it complained about unknown file type, while k3b 0.9 didn't have problems with that. Thanks a lot :) have you installed the plugins packages ? Err, yes, so it's a user error. I was confused by the 2 plugin packages It still uses a lot of cpu when burning mp3 on the fly, but the buffer is more filled now. 10 to 30 percent, instead of 0 to 10 percent. -- Marcel Pol
Re: [Cooker] dvd burning tools update hack-k3b
On Mon, 15 Sep 2003 18:16:56 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: On Mon, 15 Sep 2003 16:50:23 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: http://varna.demon.co.uk/~svetlio/ruby-contrib/mdk-cook/hack-k3b/ as i could't see it @ changelog i changed the name to k3b_0.10cvs and added some spell fixes in the DVD info messeges Thanks. I uploaded it now (didn't get around to it in the weekend). I don't have a dvd burner, so I don't think I can test the functionality that's added. I did have problems with burning mp3 and wav files on a regular cdr, it complained about unknown file type, while k3b 0.9 didn't have problems with that. Thanks a lot :) have you installed the plugins packages ? Err, yes, so it's a user error. I was confused by the 2 plugin packages :-) thanks god that there were no *.so.* for the plugins, or i might have added a 3rd one - libk3b_0.10cvs1-plugin-devel :-) didn't the plugin package required the libk3b_0.10xx-pligun package ? i think i set the dependancy I only installed the libk3b_0.10cvs1-plugin package, not the normal plugin package, which I overlooked. And yes, the dependency is set like it should, It's just not idiot-proof for people who install only the libpackage and not the real plugin package :-) It still uses a lot of cpu when burning mp3 on the fly, but the buffer is more filled now. 10 to 30 percent, instead of 0 to 10 percent. have you checked seting a manual buffer size for cdrecord or cdrdao (for example 2x or 4x the default settings) I set it to 2x (8Mb) in cdrecord, while the hardware buffer is 2Mb. I can't compare it to other apps though, I never burn mp3's on the fly in eroaster and simplecdrx, so I dunno if it's actually normal behaviour. Anyway, for me this is not important, at this point it's better then the stable version at least. -- Marcel Pol
Re: [Cooker] dvd burning tools update hack-k3b
On Mon, 15 Sep 2003 19:31:28 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: have you installed the plugins packages ? Err, yes, so it's a user error. I was confused by the 2 plugin packages I only installed the libk3b_0.10cvs1-plugin package, not the normal plugin package, which I overlooked. And yes, the dependency is set like it should, It's just not idiot-proof for people who install only the libpackage and not the real plugin package :-) is there a way to fix such problems ? I don't think a fix is needed for this. If I wanted plugins, I should have selected the k3bxxx-plugin package, not the libpackage. When people install with rpmdrake, this should work out fine. You can't make everything idiotproof. Allthough the only use of the libpackage is together with the normal plugin package by the way what does DAO mean for you ? i'm having a little discussion with one of the authors of k3b, and he says DAO == SAO in everyday language but i always thought that DAO == write a complete disk and then fixate it ( for DVD's if DAO is selected the multi session settings are disabled, for CD active) I had no clue what SAO was, but according to http://www.optorite.com/general_faq.htm#GF_Q1 it's DAO with session support. So that says it like you say it now. It would make sense to automatically fixate in DAO mode then, and make fixation and multi-session optional in SAO. I don't think it makes things clear if he merges SAO and DAO into one DAO option, if that's what he wants(?). -- Marcel Pol
Re: [Cooker] Re: iptables-1.2.8-1mdk: partly broken with 2.6.x kernels
On Tue, 19 Aug 2003 09:28:52 +0400 Andrey Borzenkov [EMAIL PROTECTED] wrote: I wanted this documented for when Mandrake includes a 2.6.x in Cooker (next to 2.4). The contrib package sounds like a nice solution until Cooker includes 2.6. At that time, something which chooses at runtime between iptables-24 and iptables-26 would be needed (like the modutils/ module-init-tools/autoconf/etc). This allows easy switching between the kernels. does iptables compiled under 2.6 work under 2.4? Sorry for the slow reply. 2.4 has more modules then 2.6, so some libraries won't be compiled under 2.6, which gives less functionality. Also, 2.6 is in contrib, and iptables is in main, so compiling it under 2.6 just won't happen anyway. anyone contacted netfilter guys and asked if this breakage under 2.6 is intentional or a bug? Good idea, I should have thought of that right away. I asked, but nothing has come out yet. I've put an iptables_kernel-2.6 package in contrib now, and it seems that this will be the fix for mdk 9.2. Olav, could you test the package? It works for me. -- Marcel Pol
Re: [Cooker] urpmi / apt4rpm - not for 9.2
On Fri, 12 Sep 2003 14:28:50 + _ cosmicflo [EMAIL PROTECTED] wrote: I could agree if apt and urpmi were only for the same purpose, but did urpmi-parallel (possibility to install on many differents machines of a cluster -may be a subnetwork-) exists for apt for example ? If this feature is so great, why don't include it in apt4rpm ? Both are opensource, no ? If you want a merge of apt and get, you'll be sure that within one month another tool will come to add another feature ... If this feature is great, why it could not be integrated ? Is it an ego issue ? It's not diversity, it's dispersion and it's not effective. I quote a reply from Pixel here, from February 24 2002 (Yes, it was discussed before :-) ) quote there was a moment where we had 2 solutions, both time costly: - dump urpmi, and switch to apt-get - enhance urpmi cons for switching to apt-get: - apt-get for rpm still needed some work - apt-get for rpm doesn't like file requires (eg: Requires: /usr/bin/perl) - apt-get doesn't handle choices (but rpmdrake doesn't either) - we don't know apt-get (which is much bigger than urpmi, currently 11Kloc vs 4Kloc) - francois doesn't like C++ anymore :) (did I say I don't either ? oops, sorry! [1]) - urpmi can be more easily tuned for the Mandrake distribution /quote -- Marcel Pol
Re: [Cooker] Re: [Bug 5454] [iptables] iptables 1.2.7a-1.2.8a NAT/MASQUERADE bug
On Thu, 11 Sep 2003 13:30:14 +0300 Thomas Backlund [EMAIL PROTECTED] wrote: [mpol] [EMAIL PROTECTED] skrev i meddelandet news:[EMAIL PROTECTED] http://qa.mandrakesoft.com/show_bug.cgi?id=5454 Which kernel (uname -a) do you run with which version of iptables (rpm -q iptables)? You should run the kernel and iptables that came with the distribution. Afaik, iptables from 9.1 will not work on a 9.2 kernel, and probably the other way around too. This is because of changes in netfilter itself. Using the iptables of 9.2 on a 9.2 kernel works ok (except for the current routing issue). Wich is fixed in my last kernel which is being worked on. Yes, I knew your kernel was already fixed, and I should have said it :-) -- Marcel Pol
Re: [Cooker] dvd burning tools update hack-k3b
On Thu, 11 Sep 2003 09:29:11 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: an update for dvd+rw-tools is needed for support of data dvd copy (and making k3b quiet ) i tried to package current cvs (anyone interested to review the spec ? , and may be upload to contrib) http://varna.demon.co.uk/~svetlio/ruby-contrib/mdk-cook/hack-k3b/ I can upload k3b into contrib, but I don't have write access in main, maybe CC'ing the maintainer or filing a bugreport in bugzilla against dvd+rw-tools is a good idea? For hack-k3b, I'd rather name it k3b_0.10 or k3b_0.10cvs or so, because it's just a cvs release, not a hacked up release, right? -- Marcel Pol
Re: [Cooker] dvd burning tools update hack-k3b
On Thu, 11 Sep 2003 18:27:34 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: On Thu, 11 Sep 2003 09:29:11 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: an update for dvd+rw-tools is needed for support of data dvd copy (and making k3b quiet ) i tried to package current cvs (anyone interested to review the spec ? , and may be upload to contrib) http://varna.demon.co.uk/~svetlio/ruby-contrib/mdk-cook/hack-k3b/ I can upload k3b into contrib, but I don't have write access in main, maybe CC'ing the maintainer or filing a bugreport in bugzilla against dvd+rw-tools is a good idea? :) 1.) bug report, that the version is not current? (pretty much packages could fall in this criteria :) ) Ah, it's also a version update... I didn't really look at that, but you will want to mail warly that you want to upgrade it from 5.11.4.6.4 to 5.12.4.7.4, and why. He only wants version upgrades in main with a good reason, and since he is also the maintainer of the package, you need him. or it causes a worning with not included package because of 1.) Ehh, just a warning, and everything works ok for the rest? Maybe the warning can be disabled in k3b_0.10 in some way? No idea yet. For hack-k3b, I'd rather name it k3b_0.10 or k3b_0.10cvs or so, because it's just a cvs release, not a hacked up release, right? should i change it, or it's not a problem for you ? Sorry, I wasn't clear. It was decided a while ago that packages which are patched by mandrake, can be called hack%name, because it's a hacked up version of the original. I think there was a cdrecord package which deserved that name. Most packages which are called hack%name are not much more then development releases from the projects cvs (hackabiword, hackeroaster), so the preferred name would then be something like k3b_0.10, or k3b_0.10cvs, like the gettext_0.12 package in contrib. Just compare it to sylpheed and sylpheed-claws, both codebases for essentially the same project. I don't really care of it should be k3b_0.10 or k3b_0.10cvs, but there are libpackages made from it also, and a libk3b_0.100 as packagename is rather confusing, while libk3b_0.10cvs0 sounds just a bit more sane :-) I can change it, that's not too much trouble. I was asking to check if hack-k3b was the right naming or not, and what your opinion is about it. -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] kernel-2.6-2.6.0-0.test4.3mdk
On Sun, 7 Sep 2003 03:18:35 +0200 Olivier Blin [EMAIL PROTECTED] wrote: Is there anyone for whom this kernel actually *works*? I haven't tried 3mdk yet, but it doesn't look like anything's fixed from the changelog. It panics early in boot (I think when it tries to mount root) on both my boxes, and I've seen two other people mention the same problem. Is there anyone out there with a working packaged test4? I'm stuck using test3, which does work... The rebuild with the latest gcc release was supposed to fix that, but it isn't fixed. The only patch applied to this 2.6-test4 are : Patch1: http://belnet.dl.sourceforge.net/sourceforge/supermount-ng/supermount-2. 0.1a-2.6.0-test4.patch.bz2 Patch30: http://members.optusnet.com.au/ckolivas/kernel/2.5/patch-test2-O10int Has someone tried to build test4 without any patch and to boot it successfully ? Yes, using the same .config as the mdk kernel, makes a bootable kernel for me. With supermount-ng and O10int, it oopses after finding my dvdrom player. So maybe the O10int patch has to be dropped, or upgraded to O18int (that's the current?). Btw, test5 is released. Oh, My compile always breaks with the cosa driver and the alsa pcmcia/vx drivers, so they were disabled. But they are modules, so that shouldn't break when booting just the kernel. -- Marcel Pol
Re: [Cooker] XFce 4
On Mon, 01 Sep 2003 21:10:40 +0200 jp4 [EMAIL PROTECTED] wrote: Is it planned to replace 3.XX versions (XFCE4-rc3 is out) No, 9.2 main is in version freeze now, so I don't think it will happen for 9.2. Sorry. -- Marcel Pol
Re: [Cooker] udftools ? too late for mdk9.2?
On Thu, 28 Aug 2003 01:18:16 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: , i just prepared two src.rpm's for udf-tools (stable 1.0.0b2 cvs 1.0.0b3) could some one review them, and may be upload them to contrib. they are pretty needed for packet cd/dvd writing and for dvd+rw used as a harddrive or dvd-ram. Would it make sense to upload them now, or is it a better idea to wait for udf write support in the kernel? PS. src.rpms are @ http://varna.demon.co.uk/~svetlio/ruby-contrib/mdk-cook/probably_broken/ specs attached and the kernel needs udf write support :( -- Marcel Pol
Re: [Cooker] udftools ? too late for mdk9.2?
On Fri, 29 Aug 2003 14:07:01 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: On Thu, 28 Aug 2003 01:18:16 +0200 (MEST) Svetoslav Slavtchev [EMAIL PROTECTED] wrote: i just prepared two src.rpm's for udf-tools (stable 1.0.0b2 cvs 1.0.0b3) Would it make sense to upload them now, or is it a better idea to wait for udf write support in the kernel? uploading them now would may be a good point to enable udf write support in the kernel, Ok, done. I've put the b3 not in the version, but in the release. (the b3 was the recommended version, or would you rather had b2? ehh, bit late to ask this now...) I also made some other small changes, but nothing major. without write support in kernel, one could may be use them to prepare packet CD/DVD's or DVD+RW, mount them in read mode, but not in read-write, so mounting -r an empty DVD+RW or packet CD doesn't make much sense alternatively one could compile the udf module from source, or i might try to make a package similar to drm-kernel , including a single module but this is rather pointless i think -- Marcel Pol
Re: [Cooker] Updating
On Mon, 25 Aug 2003 15:53:06 +0200 Dave Cotton [EMAIL PROTECTED] wrote: Has anyone found a server anywhere in the world that has actually been updated today? I have tried virtually every one from Easy Urpmi and even looked at some manually. Maybe it has to do with the making of rc1 iso's? Just a guess, but I believe this happened with the beta's as well. -- Marcel Pol
Re: [Cooker] Software submission for the Mandrake distribution
On Fri, 22 Aug 2003 04:44:50 -0700 Duncan [EMAIL PROTECTED] wrote: On Fri 22 Aug 2003 03:30, Manoj Joseph posted as excerpted below: It doesn't make the requirements, it is not free enough (similarly to freedos, which can't be compiled with free software). I am new to 'cooker'. I am not sure how things work over here... Does this mean that you guys won't touch it?? ;) Could someone tell me how decisions are made over here? Note that I'm just a cooker user/tester, but have been on the list for a bit, so weigh my opinion with that perspective.. Yes, that's basically what it means. It can never make it into the downloadable version, tho it could in theory make it into the boxed/shipped/paid version (but practically, would have to do XP/2K first, and would have to be well tested enough to be something worth being part of the paid-for version). That means this isn't the entry point you are looking for. Pushing it to the several projects who publish software for Windows will be a good idea as well. Someone already posted two url's for those projects, and I believe there are several of these. These people publish software for Windows, like The Gimp, probably explore2fs or similar software, and this software would fit right in. You target Windows users, right? I guess this is a rather grey area, some people want this software in Mandrake, some don't. But in the end it's Windows software, and there's no real need to put it on the Mandrake cd's. That's just my take on it. Perhaps try Suse, or one of the ISV/consultant firms, tho the big ones probably aren't interested due to the fact the big jobs they generally deal with are probably to big to run the dual boots in which this would be useful. A local jobber computer consultant/contractor might be /quite/ interested, however. It might even land you a job with one. shrug Meanwhile, maintaining it in decent view on sourceforge likely remains the best way to grow interest and users. -- Marcel Pol
Re: [Cooker] kernel-tmb-2.4.22-0.5.1tmb_mdk
On Sat, 16 Aug 2003 23:17:31 +0300 Thomas Backlund [EMAIL PROTECTED] wrote: %changelog * Sat Aug 16 2003 Thomas Backlund [EMAIL PROTECTED] 2.4.22-0.5.1tmb_mdk [...] - BadRAM support (udo) [...] I ran into problems with this patch. While running the kernel with this patch, I couldn't get a kernel src.rpm compiled, it broke 5 times in a different place. Using the same kernel without the badram patch makes a kernel compile in the first attempt. I don't remember having these random problems on my system for at least half a year, so I'd say the badram patch is doing things it shouldn't do. I use an smp Abit BP6 with 256 Mb sdram. Are more people experiencing problems like this? Output from dmidecode: Handle 0x0009 DMI type 6, 12 bytes. Memory Bank Socket: DIMM3 Banks: 4 5 Speed: 8nS Type: Installed Size: 256Mbyte Enabled Size: 256Mbyte [...] Handle 0x0022 DMI type 17, 21 bytes. Memory Device Array Handle: 0x001F Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 256 Mbyte Form Factor: DIMM Locator: DIMM3 Bank Locator: Bank4/5 Type: EDRAM -- Marcel Pol
Re: [Cooker] kernel-tmb-2.4.22-0.5.1tmb_mdk
On Sat, 16 Aug 2003 23:17:31 +0300 Thomas Backlund [EMAIL PROTECTED] wrote: So... Whats next... I'm looking at : working acpi for nForce (yeah... I'm dreamin' ... ;-) ...) acl support for ReiserFS courtesy of SuSe... working Via CLE and Savage dri/drm VIA AGP 3.0 bugfixes... more serial ata support - SiS, ITC, Via, intel, Promise.. vloopback support more drivers... updating old drivers... ... suggestions... please ... Suggestions: 1. The w9968cf webcam driver from: http://go.lamarinapunto.com/modules/news/ I tried making a patch, but compilation breaks: gcc -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -I/lib/modules/2.4.22-0.6mdksmp/build/include -Wall -Wpointer-arith -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wuninitialized -Wreturn-type -Wunused -Wparentheses -D__KERNEL__ -D__NO_VERSION__ -DMODULE -DMODVERSIONS -include /lib/modules/2.4.22-0.6mdksmp/build/include/linux/modversions.h -o w9968cf_core.o -c w9968cf_core.c w9968cf_core.c: In function `w9968cf_i2c_init': w9968cf_core.c:1873: error: unknown field `inc_use' specified in initializer w9968cf_core.c:1873: warning: initialization from incompatible pointer type w9968cf_core.c:1874: error: unknown field `dec_use' specified in initializer make: *** [w9968cf_core.o] Error 1 The same happens when I build it from the makefile against 2.4.22-0.6mdk I'm a non-programmer, so this is over my head. I could send you my patch if you can use it. 2. Mach64 dri from: http://dri.sourceforge.net/snapshots/bleeding-edge/ These are daily snapshots, so I'm not sure how good they are. It consists of a kernel driver and an XFree86 driver. There's a seperate website, which seems unaccessable now, and it hasn't been updated in a while I believe: http://precisioninsight.com 3. Netfilter ipt_tarpit I made a patch for it, I just need to test it. I will send it when done. -- Marcel Pol
Re: [Cooker] kernel-tmb-2.4.22-0.5.1tmb_mdk
On Thu, 21 Aug 2003 15:15:56 + FACORAT Fabrice [EMAIL PROTECTED] wrote: Le jeu 21/08/2003 à 12:28, Marcel Pol a écrit : On Sat, 16 Aug 2003 23:17:31 +0300 Thomas Backlund [EMAIL PROTECTED] wrote: %changelog * Sat Aug 16 2003 Thomas Backlund [EMAIL PROTECTED] 2.4.22-0.5.1tmb_mdk [...] - BadRAM support (udo) [...] I ran into problems with this patch. While running the kernel with this patch, I couldn't get a kernel src.rpm compiled, it broke 5 times in a different place. Using the same kernel without the badram patch makes a kernel compile in the first attempt. I don't remember having these random problems on my system for at least half a year, so I'd say the badram patch is doing things it shouldn't do. I use an smp Abit BP6 with 256 Mb sdram. Are more people experiencing problems like this? have you test your RAM ? ( memtest86 ) No, I haven't. Now that you mention it, I should do that. Who knows my ram is broken but it goes unnoticed, while this patch brings it to light... -- Marcel Pol
Re: [Cooker] Updated Bootsplash Design
On Mon, 18 Aug 2003 23:36:20 -0400 Timothy R. Butler [EMAIL PROTECTED] wrote: Thanks for the comments on the last bootsplash design. I've made it a slight bit less bright and also moved a color MDK star down over the starburst pattern. http://asisaid.com/images/mdkback.jpg As before the image is compressed and shrunk, meaning it isn't as good of quality as the real thing, blah, blah, blah. Thoughts? If you don't mind, I'm not in favour of this change. I don't think the yellow star is looking good on that place, it feels a bit glued onto there. And then white light coming from a yellow star doesn't make much sense to me. I'd like to see the mandrake star as part of the name/logo, at the left side of the M. -- Marcel Pol
Re: [Cooker] Bootsplash submissions
On Tue, 19 Aug 2003 04:11:28 -0400 Brant Fitzsimmons [EMAIL PROTECTED] wrote: Are you taking submissions for bootsplash designs? If so, I'd like to add mine. If not, I'm sorry for wasting everyone's time. http://bfcomputerconsulting.com/images/mandrake_splash.jpg I think it would look OK on a corporate desktop, but that's just my opinion. Any comments? Be gentle. ;-) I agree with other reactions, this one is really nice. Some nitpicking: Is there a reason that you didn't make the Mandrake and the L of Linux parts in italics, and have the Linux part in shadowed bold? That would make it a bit more in sync with the main logo at http://www.mandrakelinux.com/en/. -- Marcel Pol
Re: [Cooker] iptables-1.2.8-1mdk: partly broken with 2.6.x kernels
On Fri, 15 Aug 2003 22:07:39 +0200 Olav Vitters [EMAIL PROTECTED] wrote: Most iptables functions work with a 2.6.x kernel. Some (REDIRECT, MASQUERADE) do not. To fix this, 2.6.x kernels must have an iptables which was compiled against a 2.6.x kernel. Iptables 1.2.8 does not compile when /usr/src/linux points to a 2.6.x kernel. I've had to use iptables from CVS (20030813) to make it compile and had to remove the experimental stuff from the spec file. You shouldn't use a 2.6 kernel for a production firewall at this time. A few releases ago there were about 100 security patches waiting to be ported from 2.4 to 2.6. An option is to make a iptables_kernel_2.6 package in contrib, so people who still want to use it on 2.6 can do that. Would that make you happy? It will not be installable next to the 2.4 iptables because of file conflicts, but if you can live with that Example: # uname -r 2.6.0-test3 # rpm -q iptables iptables-1.2.8-1mdk # /sbin/iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 53 -j REDIRECT # --to-ports 22 iptables: Target problem # rpm -Uvh ~src/RPMS/i586/iptables-1.2.8-1.1.kernel26.mdk.i586.rpm Preparing...### [100%] 1:iptables ### [100%] # /sbin/iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 53 -j REDIRECT # --to-ports 22 # As this test shows, the iptables CVS version compiled against 2.6.x works ok. I've also recompiled the CVS version against the 2.4 mdk kernel source. This still generates an 'iptables: Target problem' error message. Note that most function of iptables for 2.4 do work under 2.6.x. -- Marcel Pol
Re: [Cooker] kernel-tmb-2.4.22-0.5.1tmb_mdk
On Sat, 16 Aug 2003 23:17:31 +0300 Thomas Backlund [EMAIL PROTECTED] wrote: I finally got it all together, and here it is: (and I have redownloaded every one and verified their md5ums...) %changelog * Sat Aug 16 2003 Thomas Backlund [EMAIL PROTECTED] 2.4.22-0.5.1tmb_mdk [...] - psaux patch for synaptics [...] It seems that this one breaks my ps2 mouse. I can use gpm and X on the 0.6mdk kernel, but not in this 0.5.1tmb kernel. If I start gpm at boottime, or later by hand, it crashes (first I can ping remotely, but after a minute it was crashed hard). also booting without gpm, and starting X gives a hard crash (agpgart/glx/dri/v4l disabled). My mouse is a Logitech cordless mouse and run an an Abit BP6 smp. -- Marcel Pol
Re: [Cooker] kernel-tmb-2.4.22-0.5.1tmb_mdk
On Sun, 17 Aug 2003 14:54:36 +0200 Marcel Pol [EMAIL PROTECTED] wrote: On Sat, 16 Aug 2003 23:17:31 +0300 Thomas Backlund [EMAIL PROTECTED] wrote: I finally got it all together, and here it is: (and I have redownloaded every one and verified their md5ums...) %changelog * Sat Aug 16 2003 Thomas Backlund [EMAIL PROTECTED] 2.4.22-0.5.1tmb_mdk [...] - psaux patch for synaptics [...] It seems that this one breaks my ps2 mouse. I can use gpm and X on the 0.6mdk kernel, but not in this 0.5.1tmb kernel. If I start gpm at boottime, or later by hand, it crashes (first I can ping remotely, but after a minute it was crashed hard). also booting without gpm, and starting X gives a hard crash (agpgart/glx/dri/v4l disabled). My mouse is a Logitech cordless mouse and run an an Abit BP6 smp. I can confirm that disabling this patch, makes my system run fine with this kernel. I can run gpm and full XFree86. So there's something going wrong between this patch and my hardware. -- Marcel Pol
Re: [Cooker] Blender Manual
On Thu, 07 Aug 2003 12:13:56 +0200 Giuseppe Ghibò [EMAIL PROTECTED] wrote: Is blender manual free from point of view of LICENSE? http://download.blender.org/documentation/html/a5384.html If so, maybe PDF and/or HTML documentation could be added to the RPM package. I'm a bit confused by part 1. You may at your option charge a fee for the media and/or handling involved in creating a unique copy of the OC for use offline, you may at your option offer instructional support for the OC in exchange for a fee, or you may at your option offer warranty in exchange for a fee. This part is ok. You may not charge a fee for the OC itself. You may not charge a fee for the sole service of providing access to and/or use of the OC via a network (e.g. the Internet), whether it be via the world wide web, FTP, or any other method. But this seems not ok. Mandrake does ask a fee for boxed sets, and it's not just a fee for the media. So that makes it non-distributable for selling on boxed sets, and incompatible with MandrakeSoft's policy, right? -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] glaxium-0.5-4mdk
On Sat, 9 Aug 2003 19:05:41 +0200 Toran Korshnah [EMAIL PROTECTED] wrote: On Saturday 09 August 2003 16:57, Leon Brooks wrote: On Fri, 8 Aug 2003 17:47, Toran Korshnah wrote: I installed the package on MD 9.1. Glaxium didn't work an still doesn't. The package was built for 9.2-beta2/cooker, not for 9.1. If you want to use packages from cooker, run full cooker, or rebuild the src.rpm (unsupported). Current libpng3 version in cooker is: libpng3-1.2.5-6mdk I started it by the K-Menu. I have a Matrox 450 32MB. The error I get, starting from a shell is as folows, [EMAIL PROTECTED] toran]$ glaxium Loading required GL library /usr/X11R6/lib/libGL.so.1.2 Depth buffer depth : 16 No stencil buffer, no shadows. Try 32bits mode. Found textures in /usr/share/games/glaxium Number of texture units : 2 Cannot load dot3 extension neither NVidia neither ARB. Fall back to basic openGL. The floor will be very simple. NO anisotropy texture... glaxium: relocation error: /usr/lib/libpng12.so.0: undefined symbol: inflateInit -- Marcel Pol
Re: [Cooker] Flash plugin
On Mon, 11 Aug 2003 10:46:31 +0100 Adam Williamson [EMAIL PROTECTED] wrote: On Mon, 2003-08-11 at 09:44, Gwenole Beauchesne wrote: On Sun, 10 Aug 2003, Edward Tandi wrote: error: Failed dependencies: libstdc++-libc6.2-2.so.3 is needed by flash-plugin-6.0.79-1 Install libstdc++2.10 You can't do that without nuking most of your installation, as it uninstalls the other version of libstdc++, which tons of packages depend on. No, the libraries are versioned, so they can coexist. # rpm -qa |grep libstd libstdc++5-3.3.1-1mdk libstdc++5-devel-3.3.1-1mdk libstdc++2.10-2.96-0.82mdk -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] abiword-1.99.4-1mdk
On Tue, 12 Aug 2003 17:20:43 +0200 John Keller [EMAIL PROTECTED] wrote: Marcel Pol wrote: - 1.99.4 Wow, you're fast. Thanks. Is this supposed to happen? (I don't know the policy for contrib packages, so please forgive me if it's normal.) - The following packages have bad signatures: /var/cache/urpmi/rpms/abiword-1.99.4-1mdk.i586.rpm: Missing signature (sha1 md5 OK) Do you want to continue installation ? (y/N) Thanks :-) Yes, it is supposed to happen. Up to now contrib packages are not signed with a mandrakesoft key. There has been some talk about implementing it, but it hasn't been done yet. -- Marcel Pol
Re: [Cooker] Flash plugin
On Mon, 11 Aug 2003 12:21:32 +0100 Adam Williamson [EMAIL PROTECTED] wrote: On Mon, 2003-08-11 at 11:17, Buchan Milne wrote: Adam Williamson wrote: On Mon, 2003-08-11 at 09:44, Gwenole Beauchesne wrote: On Sun, 10 Aug 2003, Edward Tandi wrote: error: Failed dependencies: libstdc++-libc6.2-2.so.3 is needed by flash-plugin-6.0.79-1 Install libstdc++2.10 You can't do that without nuking most of your installation, as it uninstalls the other version of libstdc++, which tons of packages depend on. $ rpm -qa 'libstdc++*' libstdc++2.10-devel-2.96-0.82mdk libstdc++2.10-2.96-0.82mdk libstdc++5-devel-3.3.1-1mdk libstdc++5-3.3.1-1mdk Wow, weird. It works here now too. Last time I tried, urpmi wanted to remove most of the system. Guess it's been fixed. That's handy! Ah, there was a bug in rpm-4.2 where it had problems with installing 2 packages with the same provides. Both packages provide libstdc++, so that's where things went wrong then. -- Marcel Pol
Re: [Cooker] eclipse
On Wed, 6 Aug 2003 22:14:58 +0200 (CEST) [EMAIL PROTECTED] wrote: Surprised i see no-one else about this, but RH provides a src.rpm for the eclipse IDE build with gcj. I think we can put it in contribs (or main?) as well? Someone feels up to it? I was planning to take at least a look at it, but the weather is just too hot to do anything besides vegetating. I'm not sure if the patches it needs for gcj are too big or not, and since I'm not a programmer I'm not sure if I can manage, but I'm willing to check it out. It seems there's no oprofile in cooker, which is listed as a buildrequires. Building that now. -- Marcel Pol
Re: [Cooker] coreutils-5.0-6mdk and termcap-devel
On Mon, 4 Aug 2003 13:31:33 -0500 AAW [EMAIL PROTECTED] wrote: The BuildRequires for this package changed from libtermcap-devel to termcap-devel in the 5mdk version. However, I can't find a termcap-devel package in cooker. I'm rebuilding the SRPMs for 9.1, so if there's been some fundamental change in the latest rpm, just ignore this. Also, the description for the doc package reads This package. I suggest the addition of contains the documentation for the GNU core utilities. Use urpmi to install software. It's provided by libtermcap2-devel. # urpmi termcap-devel Everything already installed # rpm -q --provides libtermcap2-devel libtermcap-devel = 2.0.8-34mdk termcap-devel = 2.0.8-34mdk devel(libtermcap) libtermcap2-devel = 2.0.8-34mdk -- Marcel Pol
Re: harddrake -support for dvb-cards (was: Re: [Cooker] mod_dvb anddvb cards)
On Sat, 2 Aug 2003 00:02:18 +0200 Steffen Barszus [EMAIL PROTECTED] wrote: Am Freitag, 1. August 2003 23:19 schrieb Adam Williamson: On Fri, 2003-08-01 at 15:44, Steffen Barszus wrote: Hi ! I'm currently a bit stuck. there should entries for /etc/modules.con be added. I think a postinstallscript of an application is a bad idea. The kernel too. Is this something for harddrake ??? Bullseye. Ok what infos are needed for adding support to harddrake ? Can this easy be done ? The pci-Ids are obvious I think The output of lspcidrake -v would be a good thing. Thierry Vignaud is on holiday untill August 17, and mostly he handles this kind of thing. Maybe filing a bugreport against drakxtools would be good, that way it's listed in bugzilla and won't be easily forgotten. That should be written in the modules.conf: probeall /dev/dvb dvb-ttpci alias /dev/dvb/* /dev/dvb below dvb-ttpci alps_bsrv2 alps_tdmb7 alps_tdlb7 add below dvb-ttpci grundig_29504-401 grundig_29504-491 add below dvb-ttpci stv0299 ves1820 # options dvb-core dvb_shutdown_timeout=5 # options dvb-ttpci av7110_ir_debug - More important : Can I count on that it will be done ? -- Marcel Pol
Re: [Cooker] Aug 1 Cooker will not install from hd.img
On 01 Aug 2003 07:55:26 -0400 Lyvim Xaphir [EMAIL PROTECTED] wrote: On Fri, 2003-08-01 at 06:34, Adam Williamson wrote: Ah, it's another Ron Stodden Special. Had Ron bothered to READ the archives before posting his latest instalment of self-important bile, he'd've seen the post that told us that the -BOOT kernel currently being used is the one from 9.1, and the new one will be introduced soon. And we could all have been saved from having to read more of his tripe. Pity. The real pity is being forced to see the bile being belched forth from your own punk mouth, which could benefit from a few knuckles. Oh, come on. Ron Stodden is an accepted troll on this list. There's no need to be nice to him, sometimes you need to treat people like they treat you, and that's what Adam did. I'm not trying to be offensive right now, I'm just trying to say it as it is. -- Marcel Pol
Re: [Cooker] kernel-2.4.21.6.3tmb
On Wed, 30 Jul 2003 01:21:27 +0300 Thomas Backlund [EMAIL PROTECTED] wrote: my next kernel is out: http://www.iki.fi/tmb/Cooker/kernel-2.4.21.6.1tmb-1-1mdk.i586.rpm http://www.iki.fi/tmb/Cooker/kernel-2.4.21.6.1tmb-1-1mdk.src.rpm - pci.ids 20030712 + my addons - swsusp 1.0.3, including support for xfs, acpi, splashscreen - supermount-ng 1.2.8 - agpgart support for nforce, updated intel and sis - ieee1394 rev 1010 - wireless orinoco 0.13e - cifs 0.8.2 - amd8111e 3.0.3 - bugfix for ne2k-pci, pcnet32 - update 8139cp, 8139too - via-rhine 1.1.19 - add ids to 3c59x - change Makefile mrproper to remove ipsec buildtime symlinks - update ide subsystem to 2.4.22-pre8 - based on 2.4.21.6mdk Can we send patches your way, and hope that your kernel can act as a way to get patches to Juan/Nplanel? What is the preferred way for the kernel team to accept patches anyway, if there even is something like that? Also, is your changelog your personal changelog, or is it a changelog relative to the mdk kernel on which it is based? -- Marcel Pol
[Cooker] abiword2 in main?
Hello, I have two things I'd like to mention about abiword. Can abiword2 be moved from contribs to main? There was an earlier discussion about this iirc, and the conclusion then was that abiword1 had problems with the X fontpath. This doesn't count for abiword2 anymore, so the biggest stumbleblock is out of the way. Abiword2 is rather good now, even though 1.99.3 is still numbered as devel version. It can be said that there are already wordprocessors in main, like Kword and Openoffice, but Kword is for Kde, while Openoffice is very heavyweight. Abiword is for Gnome and lightweight. Also, the same counts for Spreadsheets, Gnumeric is in main as well. In the last few years there Abiword was mentioned in a few reviews as missing on the cds, and I think it would be a good thing to have it in main at least. Also, I think abiword1 (1.0.6) can be dropped, because 1.99.3 is now really much better. It doesn't break the fontpath, and has much more functionality. Thierry is listed as official maintainer, so I don't feel I'm the one who should have the final say over it. -- Marcel Pol
Re: [Cooker] Re: Re: sitescooper and perl-libwww-perl
On Sun, 27 Jul 2003 09:16:02 -0400 David Walser [EMAIL PROTECTED] wrote: Marcel Pol wrote: I have been trying to package it with the new tarball, but the perl autoreq is *really* buggy and I can't get it not to make requires for: perl(in) perl(to) perl(Win32::Process) perl(MacPerl) Yes, that's weird. Using %define _requires_exceptions perl(in) should just work, but it doesn't. Ok, as far as this all goes, I have fixed the package. Could someone please grab: http://luigiwalser.homeip.net:8080/~david/sitescooper-3.1.2-4mdk.src.rpm and upload it? Done. The requires_exceptions now works. I haven't done anything with the errors Marcel speaks of below, so if someone cares they'll have to look into that. Isn't that the problem, that nobody cares? The upstream package and the mandrake package have been unmaintained for 2 years now. So apparently nobody cares about it. But it seems that it requires perl-DB_File, which wasn't caught be the rpm scripts. It works now, sort of. It also needs iSiloX to convert html to pdb, but that has a too restricted license to include it: http://www.isilox.com/download/iSiloXC386.htm It's only available as binary, and not allowed to modify it. So it can only download something as html, and that makes the software a lot less interesting. Wget is just as usefull then, right? Also, I get an error when I run this thing: $ sitescooper Copying default config to /home/marcel/.sitescooper/sitescooper.cf. Edit this if you need to change any configuration settings. Reading configuration from /home/marcel/.sitescooper/sitescooper.cf. Creating/editing site_choices.txt file... Running editor for site_choices.txt file using command vi... Using site choices from /home/marcel/.sitescooper/site_choices.txt. Expiring cache files... Palm install: No PalmPilot software suites are in use. Copying files to the current directory for later installation by hand. SITE START: now scooping site /usr/share/sitescooper/site_samples/regional_north_carolina/weather24_ra leig h.site. Can't locate object method TIEHASH via package DB_File at /usr/bin/../share/sitescooper/lib/Sitescooper/PerSiteDirCache.pm line 75. I'm definitely no perl guru, but according to the comments in that file it seems to be related to db dependencies, but I have these installed: db1-1.85-9mdk db2-2.4.14-8mdk libdb3.3-3.3.11-16mdk libdb4.0-4.0.14-6mdk So probably something is broken somewhere. -- Marcel Pol
Re: [Cooker] Re: sitescooper and perl-libwww-perl
On Sat, 26 Jul 2003 16:09:00 -0400 David Walser [EMAIL PROTECTED] wrote: Ok, the mistake Marcel made was he grabbed the wrong tarball. He should have grabbed that doesn't have the system perl modules in it. The source tarball in sitescooper needs to be replaced with: http://sitescooper.org/released/sitescooper.tar.gz Thanks, I didn't know that. Btw, I only touched the package to have it installable again after the rpm 4.0 = 4.2 change. The hardcoded requires on perl-libwww-perl can be removed to since the autoreq will pick that up. I have been trying to package it with the new tarball, but the perl autoreq is *really* buggy and I can't get it not to make requires for: perl(in) perl(to) perl(Win32::Process) perl(MacPerl) Yes, that's weird. Using %define _requires_exceptions perl(in) should just work, but it doesn't. Also, I get an error when I run this thing: $ sitescooper Copying default config to /home/marcel/.sitescooper/sitescooper.cf. Edit this if you need to change any configuration settings. Reading configuration from /home/marcel/.sitescooper/sitescooper.cf. Creating/editing site_choices.txt file... Running editor for site_choices.txt file using command vi... Using site choices from /home/marcel/.sitescooper/site_choices.txt. Expiring cache files... Palm install: No PalmPilot software suites are in use. Copying files to the current directory for later installation by hand. SITE START: now scooping site /usr/share/sitescooper/site_samples/regional_north_carolina/weather24_raleig h.site. Can't locate object method TIEHASH via package DB_File at /usr/bin/../share/sitescooper/lib/Sitescooper/PerSiteDirCache.pm line 75. I'm definitely no perl guru, but according to the comments in that file it seems to be related to db dependencies, but I have these installed: db1-1.85-9mdk db2-2.4.14-8mdk libdb3.3-3.3.11-16mdk libdb4.0-4.0.14-6mdk So probably something is broken somewhere. so could someone else *please* look into this? David Walser wrote: Ok, the sitescooper comes with a lot of the same perl modules provided by the perl-libwww-perl package. Furthermore sitescooper stores them in site_perl, which is wrong for packages. sitescooper should just require perl-libwww-perl (or just rely on automatic perl provides) and not ship these modules. Those modules, listed in RPM provides format are: perl(File::Listing) perl(File::Listing::dosftp) perl(File::Listing::netware) perl(File::Listing::unix) perl(File::Listing::vms) perl(HTML::Form) perl(HTML::Form::IgnoreInput) perl(HTML::Form::ImageInput) perl(HTML::Form::Input) perl(HTML::Form::ListInput) perl(HTML::Form::SubmitInput) perl(HTML::Form::TextInput) perl(HTTP::Daemon::ClientConn) perl(HTTP::Headers) perl(HTTP::Headers::Auth) perl(HTTP::Headers::ETag) perl(HTTP::Status) perl(LWP::Authen::Basic) perl(LWP::Authen::Digest) perl(LWP::Debug) perl(LWP::MediaTypes) perl(LWP::MemberMixin) perl(LWP::Protocol::data) perl(LWP::Protocol::file) perl(LWP::Protocol::ftp) perl(LWP::Protocol::gopher) perl(LWP::Protocol::http) perl(LWP::Protocol::https) perl(LWP::Protocol::mailto) perl(LWP::Protocol::nntp) perl(WWW::RobotRules::InCore) --- David Walser [EMAIL PROTECTED] wrote: Those two packages (the first from contrib and the second from main) have a lot of the same Provides. Does this look funny to anyone? __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com -- Marcel Pol
[Cooker] Re: [Maintainers] REJECTED: fonts-type1-hebrew-0.8-1mdk.src.rpmrejected
On Wed, 23 Jul 2003 09:30:18 +0200 (CEST) [EMAIL PROTECTED] wrote: New packages are not allowed * Wed Jul 23 2003 Pablo Saratxaga [EMAIL PROTECTED] 0.8-1mdk - first release I didn't see the changelog mail, but this seems like the fonts-culmus package in contribs. If you want to rename it and put it in main, I think that's fine. -- Marcel Pol
[Cooker] Re: [move] cooker contrib changes
On Tue, 22 Jul 2003 00:39:08 +0200 (CEST) tv [EMAIL PROTECTED] wrote: needed by lyx these packages has been moved from cooker contrib to cooker main: - Aiksaurus-0.15-3mdk.i586.rpm (i586) - Aiksaurus-0.15-3mdk.src.rpm (i586) - Aiksaurus-data-0.15-3mdk.i586.rpm (i586) - libAiksaurus0-0.15-3mdk.i586.rpm (i586) - libAiksaurus0-devel-0.15-3mdk.i586.rpm (i586) I had updated these packages to 1.0, but also changed the name from Aiksaurus to aiksaurus, therefore these older packages are still around. I was planning to delete them after abiword was rebuilt against the new aiksaurus, but I couldn't get abiword/abiword2 compiled with the latest gcc. Now that lyx needs aiksaurus, I guess that this version should stay, because the soname in the library changed. At least abiword-1.0.6 didn't want to compile against aiksaurus-1.0, and I guess the same counts for lyx. Should aiksaurus-1.0 be deleted from contrib, and only be put in (versioned) when abiword2 needs it? I guess that would make the most sense. -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] poweradmin-1.2.7-2mdk
On Wed, 16 Jul 2003 13:15:29 +0200
Oden Eriksson [EMAIL PROTECTED] wrote:
onsdagen den 16 juli 2003 11.47 skrev Marcel Pol:
+%dir %dir %{webadminroot}
huh?
That's what I said too :-)
It's a cut and paste typo, and fixed in 3mdk.
--
Marcel Pol
Re: [Cooker] Licensing questions
On Sun, 6 Jul 2003 17:39:45 -0700 Andi Payn [EMAIL PROTECTED] wrote: I have one specific question and some general questions about Mandrake's licensing policies. Let me start with the specific question: Frodo (a C64 emulator) allows you to use, distribute, etc. Frodo binaries and source code, and to use Frodo's source in a compatibly-licensed larger work (anything non-commercial). But you can't distributed a modified version of Frodo itself. Mandrake is a commercial distro, so if it can only be distributed non-commercially, I guess that's a No-No. Unless you get written permission from the copyright holder, but I dunno what the policy of Mandrakesoft is on that. And what does modification mean? If you place the binary in /usr/bin instead of /usr/local/bin, is that modification? Or add an icon/menuentry to it? Or patch a Makefile? Or fix a (future) compilation bug? Maybe PLF is a better place for this then. Is this appropriate for contribs? (I've enclosed the complete license at the end). And, if so, what License tag should the RPM carry? It's not GPL or BSD compatible. Not even free software, if you cannot modify it. It's open source, but not free as in free speech. You could tag it as Freeware, which means free as in beer. Check /usr/share/rpmlint/TagsCheck.py for valid licenses. Anyway, here's the Frodo license: --- CUT HERE --- The program Frodo, this manual and the source code may be freely distributed as long as they remain unchanged (archiving and packing is allowed) and all files are included. You must not make any profit by selling Frodo, especially the price of a disk containing Frodo may not exceed US$ 5,- (or equivalent amounts in other currencies). Please feel free to distribute Frodo via bulletin board systems and networks and as part of shareware/freeware CD-ROMs. Anyone using this program agrees to incur the risk of using it for himself. In no way can the author be held responsible for any damage directly or indirectly caused by the use or misuse of this manual and/or the program. The rights on the source code remain at the author. It may not - not even in parts - used for commercial purposes without explicit written permission by the author. Permission to use it for non-commercial purposes is hereby granted als long as my copyright notice remains in the program. You are not allowed to use the source to create and distribute a modified version of Frodo. Frodo is not designed, intended, or authorized for use as a component in systems intended for surgical implant within the body, or other applications intended to support or sustain life, or for any other application in which the failure of Frodo could create a situation where personal injury or death may occur. -- Marcel Pol
Re: [Cooker] Another wrong dependency ?
On Fri, 4 Jul 2003 08:38:18 +0200 Michael Scherer [EMAIL PROTECTED] wrote: On Friday 04 July 2003 01:30, Charles A Edwards wrote: On 04 Jul 2003 00:36:48 +0200 Teletchéa Stéphane [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] stephane]# urpmi imagemagic Pour satisfaire les dépendances, les paquetages suivants vont être installés (26 Mo): ImageMagick-5.5.4.4-7plf.i586 abiword-1.0.4-5mdk.i586 abiword-plugin-imagemagick-1.0.4-5mdk.i586 libMagick5.5.4-5.5.4.4-7plf.i586 libwmf-0.2.8-2mdk.i586 libwmf0.2_7-0.2.8-2mdk.i586 Est-ce correct ? (O/n) Use urpmi ImageMagick. Calling it as imagemagic results in urpmi selecting all matches, ImageMagic and abiword-plugin-imagemagick. abiword-plugin-imagemagick would then of course require abiword and its associated depends. Then this is a urpmi bug. If i do urpmi mysql, it doesn't install ( or at least , it shouldn't ) each package with mysql, such as php-mysql. It install mysql, and the real name is MySQL. MySQL provides mysql, so urpmi knows about it. ImageMagick doesn't provide imagemagick, which it probably should. I always thinked that urpmi was case insensitive, and that it was a good thing, so, clearly,this is is a bug. It should only install ImageMagick. And, if more than one package match a name( such as vim ), it should provides a selection. -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] abiword-1.0.6-1mdk
On 20 Jun 2003 10:25:56 +0200 [EMAIL PROTECTED] (François Pons) wrote: R.I.P. Deaddog [EMAIL PROTECTED] writes: On 2003-06-17(Tue) 15:48:40 +0200, Marcel Pol wrote: It still leaves me with my question about update-alternatives. Not confirmed, but my bet is: since /usr/bin/abiword is present in 1.0.4 but not 1.0.6 in %%files, rpm removes the files AFTER update-alternatives is run. That is, after running postin script in new package, it goes ahead to remove all non-existant (which it thinks so) files in the old package. Is it so, fpons? The bug concerns packages removed, not files removed. This changes nothing for abiword as /usr/bin/abiword is created by update-alternatives by %post, it does not need to be present in %files. Look at /usr/share/doc/rpm-*/triggers for documentation about which scriptlet section are executed first, you will see that if abiword-1.0.4 has /usr/bin/abiword in %files, /usr/bin/abiword is removed after %post is executed, which is probably bad, a %trigger should be used so. Thank you both for pointing out the problem. I'll see what to do with it. -- Marcel Pol
Re: [Cooker] evolution and orbit?
On Thu, 19 Jun 2003 08:43:12 -0400 Cooker [EMAIL PROTECTED] wrote: I did a little checking and found that my evolution could be crashing due to a galeon bug. My problem seems to be related to bug 4071, but reading the bug report it does not say how to reslove this issue or list any action taken. If anyone can point me in the right direction, I would greatly apprecitate it!!! Amy A. [EMAIL PROTECTED] bin]# urpmi evolution To satisfy dependencies, the following packages are going to be installed (23 MB): evolution-1.4.0-1mdk.i586 gal2.0-1.99.7-2mdk.i586 gtkhtml3.0-3.0.5-2mdk.i586 libgtkhtml-3.0_2-3.0.5-2mdk.i586 Is this OK? (Y/n) y installing [...] [EMAIL PROTECTED] bin]# evolution evolution: relocation error: evolution: undefined symbol: ORBit_c_stub_invoke [EMAIL PROTECTED] bin]# You should not install cooker packages on a 9.1 install. You should run full cooker, or run a stable release. Instead of running urpmi evolution run urpmi --auto-select which should upgrade everything to the latest in cooker (after you updated the hdlists). -- Marcel Pol
Re: [Cooker] evolution and orbit?
On Thu, 19 Jun 2003 12:30:48 -0400 Amy A. [EMAIL PROTECTED] wrote: I did a little checking and found that my evolution could be crashing due to a galeon bug. My problem seems to be related to bug 4071, but reading the bug report it does not say how to reslove this issue or list any action taken. If anyone can point me in the right direction, I would greatly apprecitate it!!! Amy A. [EMAIL PROTECTED] bin]# urpmi evolution To satisfy dependencies, the following packages are going to be installed (23 MB): evolution-1.4.0-1mdk.i586 gal2.0-1.99.7-2mdk.i586 gtkhtml3.0-3.0.5-2mdk.i586 libgtkhtml-3.0_2-3.0.5-2mdk.i586 Is this OK? (Y/n) y installing [...] [EMAIL PROTECTED] bin]# evolution evolution: relocation error: evolution: undefined symbol: ORBit_c_stub_invoke [EMAIL PROTECTED] bin]# You should not install cooker packages on a 9.1 install. You should run full cooker, or run a stable release. Instead of running urpmi evolution run urpmi --auto-select which should upgrade everything to the latest in cooker (after you updated the hdlists). I will certainly give that a try, but one of the advantages of urpmi it that it tells you the deps that will be needed. I have not heard that I should only run a 'full' cooker box and not be able to choose a specific rpm only. It's not clearly written in the cookerdevel page or in the cookerfaq, true. The message does come by on the mailinglist regularly though. It is written on those pages that you should search the archive first, before reporting, and some days ago it was mentioned that you need to upgrade bonobo and orbit, otherwise gnome will break. So you could have known :-) (evolution is a gnome package). I found using urpmi to be much more effective for installing since it grabs my deps also (except for this time ;-) Yes, but it can't grab every dependency. Sometimes things just break, like when a package is rebuilt with a new compiler (happened with gcc2 = gcc3 a lot). The maintainer of the package would need to set this manually, which will become unmaintainable very soon. Also, when using a mix of older and newer packages, it becomes very hard to determine what still works and what doesn't. There are millions of possible installs then. You can't test all these possibilities. When you follow the rule to run a stable release like 9.1, or to run full cooker, the number of possible installs becomes a lot smaller. I'm not sure if I wrote that in understandable words :-) -- Marcel Pol
Re: [Cooker] Re: [delete] cooker main changes
On Thu, 19 Jun 2003 16:13:06 +0200 J.A. Magallon [EMAIL PROTECTED] wrote: these packages has been removed from cooker main: - libgal2.0_1-devel-1.99.2-1mdk.i586.rpm (i586) - libgal2.0_1-1.99.2-1mdk.i586.rpm (i586) abiword2 still needs a rebuild to clean up old libgal's: werewolf:~# rpm -e libgal2.0_2-1.99.4-1mdk error: Failed dependencies: libgal-2.0.so.2 is needed by (installed) abiword2-1.99.1-1mdk Thanks. It's been rebuilt with the latest libgal in 2mdk. -- Marcel Pol
[Cooker] Re: [Contrib-Rpm] abiword-1.0.6-1mdk
On Mon, 16 Jun 2003 18:15:51 +0200 (CEST) Marcel Pol [EMAIL PROTECTED] wrote: [Contrib-RPM] Name: abiword Relocations: (not relocateable) Version : 1.0.6 Vendor: MandrakeSoft Release : 1mdk Build Date: Mon Jun 16 17:57:06 2003 [...] +update-alternatives --install /usr/bin/abiword abiword /usr/bin/abiword-1.0 20+ %postun +[ $1 = 0 ] || exit 0 +update-alternatives --remove abiword /usr/bin/abiword-1.0 + When I have abiword 1.0.4 installed and upgrade to 1.0.6 strange things happen. Version 1.0.4 has a symlink /usr/bin/abiword which points to a wrapper script. Version 1.0.6 uses update-alternatives. After the upgrade there is a symlink in /etc/alternatives, but there's no symlink in /usr/bin, which points to /etc/variables. Also, abiword and abiword2 both provide abiword. Upgrading abiword works fine. But when I urpmi abiword2, it deinstalls abiword (1). The packages don't conflict, so apparently it has to do with both packages providing abiword. Anyone can tell me what I'm doing wrong, and what exactly is happening? -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] abiword-1.0.6-1mdk
On 17 Jun 2003 15:17:08 +0200 [EMAIL PROTECTED] (François Pons) wrote: Olivier Thauvin [EMAIL PROTECTED] writes: Le Mardi 17 Juin 2003 14:55, Marcel Pol a écrit : Also, abiword and abiword2 both provide abiword. Upgrading abiword works fine. But when I urpmi abiword2, it deinstalls abiword (1). The packages don't conflict, so apparently it has to do with both packages providing abiword. rpm bug explain by fpons: you have A installed providing Z you install B providing Z rpm will remove A. Yes, it has just been fixed, bug in rpm fixed in rpm-4.2.1 with backport to original rpm. Thanks. I guess this was already covered in another thread. I should probably read better. It still leaves me with my question about update-alternatives. -- Marcel Pol
[Cooker] pnet-devel obsoletes pnet
The pnet-devel package obsoletes the pnet package. This makes that when you have pnet installed, it gets updated to pnet-devel, which shouldn't happen. Removing the provides/obsoletes from the specfile should fix it. From the specfile: %package devel Summary: Headers for developing programs that will use %name Group: Development/C Provides: %name-devel = %version-%release Obsoletes: %name Provides: %name -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] monodoc-0.4-1mdk
On Wed, 11 Jun 2003 10:27:05 +0200 Michael Reinsch [EMAIL PROTECTED] wrote: * Sun Jun 08 2003 Marcel Pol [EMAIL PROTECTED] 0.4-1mdk - initial Mandrake rpm. 1) It also requires libxslt1-devel, otherwise you'll sometimes get: ** (unknown:17963): WARNING **: Failed to load library libxslt.so (xslt): libxslt.so: cannot open shared object file: No such file or directory Thanks, I missed that one. Do you know if there is a utility like ldd for mono based software? 2) /usr/lib/monodoc/sources/netdocs.zip is broken: # unzip -t /usr/lib/monodoc/sources/netdocs.zip Archive: /usr/lib/monodoc/sources/netdocs.zip error [/usr/lib/monodoc/sources/netdocs.zip]: start of central directory not found; zipfile corrupt. Hum, weird. It seems that a parallel make breaks it. It runs the same command twice at the same time apparently? 2mdk should be fixed. -- Marcel Pol
Re: [Cooker] apache config gui
On Tue, 10 Jun 2003 23:36:26 +0200 Oden Eriksson [EMAIL PROTECTED] wrote: I have just tried comanche3-0b4 the apache config gui and it sucks..., just wanted you all to know this. Maybe the redhat 9 apache2 config gui is slightly better, or just works better? (just wanted to try and be innovative for 9.2;)) Does the webmin module work good for apache2? This morning or yesterday there was someone asking that same question on irc, and nobody really knew. I'm just asking, because the config for mandrake's apache is rather customised, and a lot of people use webmin. -- Marcel Pol
Re: [Cooker] Development extranet for non-intel builds [ALPHA:SPARC:PPC:X86_64]
On Sun, 08 Jun 2003 09:36:05 +0200 Stefan van der Eijk [EMAIL PROTECTED] wrote: At the moment, to my knowledge we have the following machines _dedicated_ to non-intel cooker development (please, developers, fill in all blanks): Alpha - 2 x XP1000 - CSC still 7.1b - need help with this - 1 x PWS433au - Stefan Van Der Eijk - 1 x PCI33 - mpol - 1 x ??? - Juan - 1 x DP264 - Paris office (same as Juan's?) - others? SPARC - 1 x SparcStation 10 SMP - Olivier Thauvin - 1 x SparcClassic - CSC (unused - 32 bit system) - 2 x Ultra 10 - CSC - 1 x Ultra 5 - CSC - others? PPC - 1 x Titanium G4 500, 512 Mo Ram - Olivier Thauvin I also have an oldworld PowerMac 185 Mhz, 96 Mb ram. It's mostly too slow to compile anything, but it does run cooker. I believe Ben Reser has a few ppc machines, but I don't know if he runs cooker on it. - others? x86_64 - 1 x Dual Opteron 240 - CSC (ETA 15 days) - others? PA-RISC - 1 x HP 9000 D-class model D390/800 - Stefan van der Eijk (on loan during the summer) I have one HP box but don't know if linux can run on it. Will looking. I booted the debian installer on it yesterday. So it should run Linux. The box has 2* 8200 CPU's (240MHz, 4Mb cache each), 1Gb RAM and 2* 9Gb disk. And it's huge (60*26*55cm) heavy (45kg). I wasn't seriously thinking about porting mdk to it. The plan was to install debian and hand it back to it's owner (the local scouting group) but since they don't need it till after the summer, I might try mdk anyway :-) MIPS - 1 x SGI IRIS Indigo - Stefan van der Eijk (RAM defect?) This box is probably too slow to do anything usefull. -- Marcel Pol
[Cooker] Re: [CHRPM] pspell-0.12.2-8mdk
On Thu, 5 Jun 2003 01:00:25 +0200 (CEST) Per Øyvind Karlsen [EMAIL PROTECTED] wrote: --=-=-= Name: pspell Relocations: (not relocateable) Version : 0.12.2Vendor: MandrakeSoft Release : 8mdk Build Date: Thu Jun 5 00:48:06 2003 Install date: (not installed) Build Host: klama.mandrake.org Group : System/Libraries Source RPM: (none) Size: 299741 License: GPL Packager: Per Øyvind Karlsen [EMAIL PROTECTED] URL : http://pspell.sourceforge.net/ Summary : Portable Spell Checker Interface Library Description : The goal of the Portable Spell Checker Interface Library (Pspell) is to provide a generic interface to Spell checker libraries installed on the system. Could this package be deleted from the mirrors? Pspell is now provided by the aspell package, it was merged upstream a while ago. -- Marcel Pol
Re: [Cooker] libwpd and wpd2sxw
On Sat, 31 May 2003 16:25:01 +0200 Torstein Dybdahl [EMAIL PROTECTED] wrote: I have made packages for libwpd 0.5.0 (updated) and wpd2sxw from the libwpd project http://libwpd.sf.net the packages is available at snuppa.mine.nu/mandrake/ If someone is able to uploade them to contrib it would be nice. Thanks, I'll take a look :-) -- Marcel Pol
Re: [Cooker] libwpd and wpd2sxw
On Sat, 31 May 2003 16:25:01 +0200
Torstein Dybdahl [EMAIL PROTECTED] wrote:
I have made packages for
libwpd 0.5.0 (updated) and
wpd2sxw
from the libwpd project http://libwpd.sf.net
the packages is available at snuppa.mine.nu/mandrake/
Thanks, I didn't apply all your changes though. The libwpd-tools package
should not be renamed to libwpd0-tools or now libwpd-1.0-tools; it's not a
library package so it shouldn't follow the library policy.
I was a bit confused by mandrake's libpolicy, where I looked at libgsf.spec
for an example. It used:
%define lib_name%mklibname gsf- %{api_version} %{lib_major}
instead of:
%define lib_name%mklibname gsf %{api_version} %{lib_major}
(Note the dash)
What is the reason of the dash? Most packages don't have them. Can someone
enlighten me on it?
--
Marcel Pol
Re: [Cooker] Spec file for Web Meta Language (wml.spec)
On Sat, 31 May 2003 12:29:24 +0300 (IDT) Shlomi Fish [EMAIL PROTECTED] wrote: Check: http://t2.technion.ac.il/~shlomif/wml.spec For a spec file for Web Meta Language 2.0.9 (http://thewml.org/). Now the question is: how do I incorporate it into the core Cooker distro? It's already in Mandrake, with the same version. If there's anything you'd like to have changed in the current specfile, then send a diff against that specfile and send it to the list. You will also want to cc to the maintainer, not everybody reads the cookerlist, so mostly that's a good idea. Lenny is listed as maintainer, as you can see with: rpmmon -p wml -- Marcel Pol
Re: [Cooker] New/fixed packages: gtk-sharp-0.8-1mdk,mono-0.23-3mdk, gnome-db-0.2.96-7mdk
On Fri, 4 Apr 2003 12:51:01 -0800 Andi Payn [EMAIL PROTECTED] wrote: The mono-0.23-2mdk package installed broken scripts in /usr/bin/msc and /usr/bin/mbas that pointed into the packager's build root. The problem is that the script that generates these scripts expects to find the real binaries in the install directory, which obviously isn't true when you're packaging. This should probably be fixed properly with the mono people; for now, I just added two lines to the specfile to overwrite these scripts. Mono-0.23-3mdk should be fine. The rest of these packages were already submitted by Quel Qun, but they needed some work for the libpolicy, and I've been a bit slow on that. Do you have a webspace where you can put these src.rpms? I don't have read access to /incoming. The gnome-db-0.2.96-6mdk package didn't include pkgconfig support, and wouldn't build without errors (because it installed but did not package the help files). The gtk-sharp package requires my updated mono and gnome-db devel packages to build, but binaries should install just fine with the existing versions. The mono packages don't install the monodoc tools or the mono documentation, so I didn't install the Gtk# docs either. This should probably be changed in the future (or maybe separate monodoc, mono-docs, and gtk-sharp-docs packages would be better?). Someone should package Qt# (especially given Mandrake's slight Qt/KDE preference), but it might be a while before I get around to it (since I've barely even looked at Qt#). -- Marcel Pol
Re: [Cooker] Why do we have pspell?
On Mon, 24 Mar 2003 08:14:53 +0100 Oden Eriksson [EMAIL PROTECTED] wrote: Why do we still have the pspell package(s) in the distro? It conflicts with aspell, and I've heard from others that aspell provides a pspell library. Also, nothing in the distro appears to require the pspell packages. php-spell Pspell has been merged with aspell, so the original pspell packages should probably be dropped. The package libaspell15-devel provides a header for pspell, and libaspell15 provides pspell libraries. Php-pspell compiled against it, I have not tested if it also works. If it doesn't, it's probably a bug in the pspell libs in current aspell. -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] hackabiword-1.1.3.1-1mdk
On Sat, 22 Mar 2003 15:36:59 -0500 Charles A Edwards [EMAIL PROTECTED] wrote: On Fri, 21 Mar 2003 01:00:59 +0100 (CET) Marcel Pol [EMAIL PROTECTED] wrote: Name: hackabiword Relocations: (not relocateable) Version : 1.1.3.1 Vendor: MandrakeSoft Release : 1mdk Build Date: Fri Mar 21 00:33:01 2003 Install date: (not installed) Build Host: klama.mandrake.org Group : Office Source RPM: (none) Size: 10829782 License: GPL Packager: Marcel Pol [EMAIL PROTECTED] %package plugin-xhtml Summary: Plugin to enable import of arbitrary HTML and XHTML documents. Group:Office Requires: libxml2 hackabiword ^^^ BuildRequires:libxml2-devel Provides: abiword-plugin-html ^^^ Obsoletes:abiword-plugin-html ^^^ The above lines for Provides/Obsoletes need to be changed to hackabiword, as it causes urpmi to install hackabiword-plugin-xhtml-1.1.3.1-1mdk and hackabiword-1.1.3.1-1mdk if Any version of abiword-plugin-html is found. In my case abiword-plugin-html-1.0.4-5mdk Yes, of course. Sorry for that. -- Marcel Pol
[Cooker] Re: [Contrib-Rpm] mono-0.23-1mdk
On Tue, 18 Mar 2003 12:00:37 +0100 (CET) Marcel Pol [EMAIL PROTECTED] wrote: [Contrib-RPM] Name: mono Relocations: (not relocateable) Version : 0.23 Vendor: MandrakeSoft Release : 1mdk Build Date: Tue Mar 18 11:52:12 2003 URL : http://www.go-mono.com/ Summary : Mono Runtime. Description : Mono is an implementation of the ECMA Common Language Infrastructure, it contains both a just-in-time compiler for maximum performance, and an interpeter. It can also be used to run programs from the .NET Framework. Could someone from MandrakeSoft look into this, if they want this included in the distro (contribs)? Ximian claims in their faq that there are no patenting issues, but that could be considered a naive point of view. I can imagine that MandrakeSoft doesn't like to risk a lawsuit from Microsoft about unlicensed IP or patents, etc. If there's a decision that it's not going to be included it should be moved to PLF. -- Marcel Pol
Re: [Cooker] Re: [Contrib-Rpm] mono-0.23-1mdk
On Tue, 18 Mar 2003 14:03:42 -0800 (PST) Quel Qun [EMAIL PROTECTED] wrote: [Contrib-RPM] Name: mono Relocations: (not relocateable) Version : 0.23 Vendor: MandrakeSoft Release : 1mdk Build Date: Tue Mar 18 11:52:12 2003 URL : http://www.go-mono.com/ Summary : Mono Runtime. However, it would be more useful with gtk-sharp and this requires libgda2, libgnomedb2 and gtksourceview. All this in /incoming if you want them. The docs seem a bit broken, but the libs are fine. I don't think all this is mature enough to go in main, but it definitely should be in contrib. My main target was to add mod_mono to apache, which can serve asp pages. But what you are doing might be just as interesting :-) I don't have access to incoming, do you have a webspace to put it on? -- Marcel Pol
Re: [Cooker] Post 9.1 Wishlist
On Tue, 18 Mar 2003 14:24:41 -0500 Austin [EMAIL PROTECTED] wrote: 5. New menu entry for 'home and hobby' type applications. I've asked for this a few times... no response. There are a lot of apps that should go in this category. I think Joe user would look for a recipe application is 'home and hobby' rather than 'databases'. Similarily, putting gramps in 'sciences' is a bit of a stretch, and I have some 'homework' applications that don't really belong in 'office'. Home and hobby is amusement, right? So maybe it should have a submenu under amusement. -- Marcel Pol
Re: audio cd duplication
On Tue, 18 Mar 2003 19:33:11 +0100 Matthieu Amiguet [EMAIL PROTECTED] wrote: I'm looking for a way to duplicate an audio CD in dao mode and on-the-fly. I know my machine is fast enough to do it as I can do it under macos, but I could not find how to do it under linux. I tried xcdroaster, eroaster, gtoaster and gcombust: They all recognize my usb burner, and they can recognize my ide cd reader if I use scsi emulation (which is not very convenient, but I can do with it if necessary). But I could find no way to burn dao on the fly. I did not try with the command line tools as I don't know them well. Maybe cdrdao/gcdmaster can do it on the fly? I'm not sure though. A disadvantage is that it uses cdda2wav as a ripper, instead of cdparanoia. Cdda2wav doesn't have good error correction, while cdparanoia has. Personally I just don't care about on the-fly-burning, especially with audio. Ripping audio with error protection gives maybe a speed of 3x or 5x, so it can be tricky for the burner to not let it make a coaster. If you have a burner with burnproof it might be fine though. -- Marcel Pol
Re: [Cooker] urpmi features
On Tue, 18 Mar 2003 00:52:04 +0100 Stefan van der Eijk [EMAIL PROTECTED] wrote: Levi Ramsey wrote on Mon, Mar 17, 2003 at 12:39:17PM -0500 : I'm going to working on a an automatic rebuild capability (somewhat Gentoo-ish)... I've been thinking of doing this for a while, and the time for action draws near... ;o) Something like a urpmb command? One that will automatically fulfil the build requires (requiring temporary root elevation)... yeah... if the BuildRequires would be correct. Major hurdle here... A bit offtopic in this thread... Last week the idea came up to have your buildscripts post to bugzilla on failed packages. What do you think of it? Those scripts do make it obvious what buildrequires are needed/missing, though even then it is time consuming to fix them, especially for hundreds of packages :-( -- Marcel Pol
