Re: [Cooker] naming policy
On Friday 25 July 2003 08:31, Michael Scherer wrote: Some of them are named foo-python, and the others are named python-bar. example adns-python, libxslt-python vs python-xoltar, python-fam There are two important distinctions here that are being missed. First, adns-python and libxslt-python are python interfaces to the standalone packages adns and libxslt; python-xoltar is a standalone set of extensions to the python standard libraries (there is no xoltar package). Second, adns-python and libxslt-python come from the same tarball (or another tarball on the same project site) as adns and libxslt; python-xoltar is a project on its own. In other words, this is just like the difference between gimp-perl (the perl interface to gimp, distributed with gimp) and python-Inline (an extension to the perl standard libraries, distributed as Inline in CPAN). The rule of thumb that perl packages seem to follow is: If the package's primary source is CPAN, the package is perl-Foo-Bar, where Foo::Bar is the CPAN name; if the primary source is the foo distribution,the package is foo-perl. Do we want to change this rule to always use the perl-Foo-Bar style of naming? Or is it better to just codify the existing de facto rule, and extend it to python (which would mean the vast majority of existing perl and python packages are already named correctly)? Note that python doesn't have a real equivalent to CPAN (for example, there's no Starship entry for xoltar, or cRat, or perlmodule). This also means that it's harder to figure out a canonical name for a package. If the Xoltar website has a tarball called xoltar which includes no files named xoltar, is the resulting package python-Xoltar or python-xoltar? If the CRat website has a tarball called cRat which builds a module called crat.so, is the package python-CRat, python-cRat, or python-crat? (For the modules I've packaged, I've used the name of the tarball.)
Re: [Cooker] dnotify startup script
On Tuesday 22 July 2003 09:51, Ben Reser wrote: Done and attached. The README file that is attached should go in /etc/sysconfig/dnotify.d for documentation purposes... One more problem: If you do have an /etc/sysconfig/dnotify, but it consists of nothing but comments, then service dnotify start will do nothing (and report FAILED), but it will touch the lockfile anyway. So service dnotify status will report dnotify dead but subsys locked, and service dnotify stop will fail. Maybe you should do an extra grep along with the -r tests to exit early if the config files are empty: --- dnotify.init.old +++ dnotify.init @@ -21,2 +21,5 @@ +egrep -shv '^([[:space:]]*#|[[:space:]]*$)' /etc/sysconfig/dnotify \ +/etc/sysconfig/dnotify.d/* /dev/null || exit 0 + RETVAL=0 Otherwise, it all seems to work for me. And this is definitely useful. You should send it to the upstream author to see if he's interested in it. And we should either add it to the dnotify package in contribs, or package it up on its own.
Re: [Cooker] RedHat trying to beat us at our own game?
On Wednesday 23 July 2003 00:22, Jaroslaw Zachwieja wrote: On ro 23. lipca 2003 03:34, Olivier Thauvin wrote: managing quality on contrib packages WHAT contribs? FreshRPMS? Sorry (to RH ppl) but their off-distribution packages are kinda umm... quantum ;) Officially something's there, but in real life it's either broken or nonexistant (or for 6.2:) Actually there are many packages out there for Redhat 9, it's just that Redhat doesn't distribute them. I'd say that about half the new things I've packaged up for Mandrake contribs had a RH9 package (or RH8.x). (Scan the changelogs and you'll often see that the first comment says based heavily on RH specfile from tarball or used specfile designed for RH9 as a starting point or something similar.) The first practical effect of their big policy change is going to be that all of these packages suddenly become official Redhat contribs. This should not only make them easier for people to find, it should also mean more validation on the packaging, quicker updates (if the developer doesn't have the new RH beta, probably one of her users does), etc. On the other hand, the fact that it's so much easier to get stuff into Mandrake contribs may be part of the reason why, despite there being so many Mandrake-based developers out there, so few people put mdk RPMs on their sites. Or maybe it's just that Mandrake specfiles look so much more complicated (when actually they're simpler--more macros = less work, less chance for stupid errors, etc.). PS. Isn't anyone bothered with first line of my mail? I think KMail should have ability to bind language to profile. But this is wrong mailing list to bitch about it, I know :) If I can (barely) live without client-side IMAP filtering, do you think something as minor as that is going to make me switch to Evolution? But actually, this sounds like a simple issue; it should be relatively easy to make a patch, and get it into kdenetwork (as opposed to client-side IMAP filtering--making a patch for that is nontrivial, and getting it accepted is nearly impossible). Meanwhile, Michael Scherer replied: Of course, plf people never talked to any mdk people, they live in a different country, and, there is no connection between them. Nah, they all live in France. So do all contributors. All the .ca, etc. addresses are just a ploy to confuse us. And PLF is an insidious French plot to subvert good honest American laws that are meant to take the rights from citizens of all countries and put them safely where they belong, in the hands of American media/technology conglomerates like CBS, NBC, Fox, Virgin, etc.
Re: [Cooker] URPMI --auto-select --auto removed KDE
On Tuesday 22 July 2003 21:28, Paul Misner wrote: I might agree, except I really am trying to help, I am not an expert with either Linux, or the Mandrake tools, and I don't know what urpmi --bug is, since it is not list in man urpmi. Really? You have urpmi-4.4-9mdk. So do I. On the man page, right after --proxy-user, and right before --env, I see: --bug directory Create a bug report in directory, you have to send a compressed archive of the directory to urpmi maintainer for the bug being (problably) fixed. Also, in urpmi --help, between proxy-user and env, it says: --bug - output a bug report in directory indicated by next arg. The problem may be that --bug is listed, but you're using a UTF console, so searching the manpage (within less, which is called by man to display the man) fails to find hyphens? Or maybe you're on a different platform (PPC, Alpha, whatever) and the manpage for your platform is somehow wrong? Or your catman is screwed up and you have an old preformatted urpmi manpage sitting around blocking you from seeing the real one? Anyway, if this actually isn't there on your system, that sounds like a bug worth reporting.
Re: [Cooker] RedHat trying to beat us at our own game?
Last time I used Redhat (admittedly quite some time ago), individual and non-commercial users could register one computer for up2date for free; it was only corporate users who had to pay for it. Also, I believe that the software for up2date and the corresponding server are free. If so, there's nothing stopping a group of users from making a free Redhat mirror with a modified version of up2date that points at that mirror. Well, nothing except the fact that users who think that way tend to be the same users that switch to Mandrake or Debian or Gentoo or whatever after Redhat has served as their introduction to linux. And I've heard third-hand that apt-get works very well on conectiva and on PLD, so making it work on Redhat (or Mandrake) shouldn't be all that hard. Meanwhile, FACORAT Fabrice wrote: Le mer 23/07/2003 à 10:15, Andi Payn a écrit : And PLF is an insidious French plot to subvert good honest American laws that are meant to take the rights from citizens of all countries and put them safely where they belong, in the hands of American media/technology conglomerates like CBS, NBC, Fox, Virgin, etc. virgin is english And CBS is Japanese, and Fox is Australian, and so forth. That's the point. In fact, off the top of my head, other than Turner, AOL/Time/Warner, and Disney, nothing in the American media is American. And Levi Ramsey wrote: I imagine that the tripping of Lance Armstrong on the Luz-Ardiden was part of that nefarious PLF plot ;o No, that was an RH9/CIA agent; Lance Armstrong himself is a PLF plot. He was built and packaged at the secret PLF laboratories under the squash courts at CNRS Service d'Aéronomie by a slave army of penguins and north Africans, under direction of the French Ministry of Inconveniencing George W. Bush (which secretly controls all governments in Europe except Spain and England). Any attempt to get Americans interested in a French event, sponsored almost entirely by European companies, in a sport that the average person enjoys participating in more than watching on TV, is obviously an anti-American plot.
Re: [Cooker] RedHat trying to beat us at our own game?
On Wednesday 23 July 2003 06:48, Stefan van der Eijk wrote: Main difference (IMHO, from what I've seen): * urpmi is a cash generator. You need to pay (or tollerate being nagged every 60 days) to use it; I think you mean up2date is a cash generator; urpmi is more a cash drainer for Mandrake: They pay people to code urpmi and keep the repositories up to date, but since not a single Mandrake user knows how cool urpmi is it generates $0 in new sales. Of course if everyone knew how cool urpmi was, that'd be a different story. I recently managed to get someone off of Debian after two years of listening to him bitch about how Woe is me, Debian is so out of date, but I can't live without apt-get, and I can't believe anything like that could work for rpm. * up2date can't connect to more media. With urpmi it's possible to configure multiple media and have different media servicing different environments -- /chroot/9.0 uses --media=9.0, /chroot/9.1 uses --media =9.1, etc) If you run up2date from within the chroots (using /chroot/8.1/usr/sbin/up2date, /chroot/9/usr/sbin/up2date, etc., and the corresponding /chroot/*/etc/whatever-up2date-uses) they can each have their own media (by selecting a different service and/or by having a different /etc/redhat-release file). What you can't do is update a _single_ environment from multiple media (e.g., the way most people have main, contribs, update, and plf as media and urpmi searches all of them). * Nice thing about up2date is the web interface where it's possible to manage packages on your system(s); If we got gnorpm working again, we'd have the same functionality, wouldn't we? And you forgot another big difference: * up2date has an automated update system, which (IIRC) can tell you when new updates are available, optionally automatically download them for you when your online and idle, and even more optionally automatically install them for you. Has anybody provided an alternative service for RHN / up2date? This should be possible, since which service you connect to is configureable, and the up2date software itself is open. Just putting the server part together. I think the server software is also open source. So just get a server and run it, right? Leverage the Internet mirrors or torent, and price it at 50% of what RHN costs... You can't call it RedHat, then make it RedCapNetwork...Why not? In my last post, I suggested a group of Redhat users running such a service for free. But yeah, I guess the same idea could also be used to run the service for half price. RedCapNetwork could still be a trademark violation; if your name is intended to or likely to confuse or mislead a reasonable customer, you can't use it. So, if you're sure it'd be obvious to any reasonable person you (or Redhat's lawyers) can imagine that RCN isn't the same thing as RHN, you'd be fine, but I'm not sure it is, and Redhat probably has better lawyers than you. Why not just call it Up2date Network? Or, if they've trademarked up2date just RPM Update Network. RedHat made a biz-model out of keeping systems up2date, which makes sense. Mandrake built a technically superior product (IMHO), but just forgot the biz-model... I doubt up2date is a substantial piece of Redhat's revenue; I just don't see how a subscription service for a free distribution that anyone else can give away updates for isn't going to make you rich. Especially when you give it to individuals and non-commercial organizations for free, and you throw it in with the service contracts you sell to corporate customers. Now, if you throw in a few proprietary programs (which users _can't_ just share with each other or set up their own mirrors for)... well, then you have MandrakeClub minus the goodwill. Which might make you half as rich and successful as Mandrake
Re: [Cooker] RedHat trying to beat us at our own game?
On Wednesday 23 July 2003 09:54, Luca Olivetti wrote: Andi Payn wrote: On the other hand, the fact that it's so much easier to get stuff into Mandrake contribs I beg to differ. I took more than a year to get cyrus-imapd in contribs. Not saying it's as easy as it ideally should be, just that it's usually much easier than getting stuff into Redhat. (Which is why freshrpms and similar collections exist.)
Re: [Cooker] RedHat trying to beat us at our own game?
On Wednesday 23 July 2003 13:13, Stefan van der Eijk wrote: Andi Payn wrote: Not saying it's as easy as it ideally should be, just that it's usually much easier than getting stuff into Redhat. (Which is why freshrpms and similar collections exist.) actually, we should try to get some agreement on packaging standards with RedHat, or at least, with their contributors, so that at least these contrib archives can be merged... or am I being the idealist again? I agree with you, but yes, you probably are. In fact, I think we had essentially this same discussion around the time of the 9.1 beta, and most people thought we were being too idealistic. What you're looking for is a system to ensure that, without access to both both Redhat and Mandrake boxes, a contributor can create a package that will build on either (I don't think it's necessary that, having been built on one, it will install on the other). Right? I've thought about this before, and I can write up a concrete proposal for the tools and policies needed, if people other than Stefan are interested. If not, I won't waste my time and the list's bandwidth. By the way, has anyone wondered whether Redhat has any interest in more cooperation with Mandrake? It's all well and good for Mandrake developers and contributors to look for ways to help Redhat be more like our favorite distro, but it's always possible they'd look at it more as hostile subversion than as altruism
Re: [Cooker] dnotify startup script
On Tuesday 22 July 2003 00:30, Dave Cotton wrote: Does this mean MIME-defang works? Apparently. But is it possible to configure it to move all that text except the first sentence to the end of the message? It's a bit annoying to have to scroll through 40-odd lines of wordy warnings to get to the 10-line message. Also, what exactly did MIME-defang do in this case? As a guess, it seems to have converted text/plain attachments with useful names into application/octet-stream attachments with meaningless names, apparently without changing the content at all. Which means that you have to skim the warnings to figure out which file is which--and, at least for kmail users, that they open in kwrite instead of in your default text editor (or inline, or in the built-in text viewer). What is this protecting us from? Finally, it's a bit strange to say, ... if you were not expecting a file of this type... and never mention what type the file originally was. Couldn't MIME-defang say, An attachment named 'foo' of type 'mime/type' was converted...?
Re: [Cooker] dnotify startup script
I wanted to setup dnotify to automatically rebuild my hdlists for my mirror. But I also wanted to make sure it always started. So I wrote a small init script for it. Attached is a conf file to put in /etc/sysconfig/dnotify and an init script to put in /etc/rc.d/init.d/dnotify. Unless you configure dnotify args it will not start dnotify even if you have it enabled. So it's safe to add to the package and enable by default. :) I agree; this would be a useful thing to add to the standard dnotify package. But I'd suggest two minor changes. It might be better to have an /etc/sysconfig/dnotify.d directory instead of a single file. This is easy, and potentially useful (e.g., for future packages to drop their own dnotify commands in place). Also, I think better examples would be very helpful. Yeah, it's not too hard to figure things out from the manpage, but on the other hand, the examples that are provided. are more apt to be confusing than helpful to a newbie. Running dnotify -A /etc -e echo change will print change whenever a file in /etc is read--but not when a file in /etc is changed. And the other example will call informdelete whenever a file in /var/mail is deleted, but also whenever one created. So, it'll be triggered whenever a mailbox is created or destroyed, which is unlikely to be a good reason to call something called informdelete. So, both of the examples are more likely to confuse than enlighten newbies. Also, the first example will print change to stdout, which is not likely to be what you want in a program backgrounded by an init script. And the second will likewise print its output to stdout--and, if informdelete returns nonzero, dnotify will print a warning to stderr. So, examples showing redirection would also be nice. And, since dnotify will run everything as root, examples showing dropping root might be handy. Finally, it would be nice to have examples of something someone might want to actually do. Something like this: -CDMRB -r /etc/httpd -e service httpd configtest /var/log/dnotify -CDMR -p1q0 /var/mirror/urpm -e su -c'/usr/local/bin/rebuildhdlist /var/log/urpmirror' urpmirror etc. It might even be better to have cron-ish TSV/CSV/whatever config files, so it could just be something like: #cond dir recurse procs queues user stdout[:stderr[:dnotifyerr]] cmd CDMRB /etc/httpd r - - - - service httpd configtest CDMR /var/mirror/urpm - 1 0 urpmirror /var/log/urpmirror:- /usr/local/bin/rebuildhdlist But that's probably overkill. Just a /etc/sysconfig/dnotify.d and a set of useful examples, and I'd be more than happy. By the way, has anyone noticed that the notify manpage says that --all is shorthand for -AMCDRO when actually it's -AMCDRB? I seem to remember there used to be a -O flag (the possible flags were -DMACRO, which was an easy mnemonic for anyone who's ever compiled a C program), probably for chown? Anyway, I sent an email to the original author about that.
Re: [Cooker] gtkextra and guile for Gtk 2?
On Monday 21 July 2003 21:23, Abel Cheung wrote: On 2003-07-20(Sun) 06:11:22 -0700, Andi Payn wrote: No, sorry; nothing to do with guile here. I meant that (just as with guile), there is no package for the gtk2 port of gtkextra. If you have an up-to-date package, please upload it. (If you're concerned that no package needs it, well, now we have one: gnubg.) Or I can package it, if you don't want to bother. It's here: http://deaddog.org/Mandrake/cooker/contrib/SRPMS/gtk+extra1.1-1.1.0-0.20030 629.1mdk.src.rpm AFAIK the GTK2 port has never been distributed, and only lives in CVS so far. It's in a bad shape too (I have to modify a few places so that it can build). But I really don't know where to upload it (don't want to dump that to /incoming and be ignored). If you want a newer CVS checkout, I can finish it shortly. If it's nowhere near complete, and the only package that wants to use it is gnubg, and gnubg seems to run just fine without it, it's probably not worth bothering. I'll download and play with your package anyway just for the hell of it, but I doubt it needs to go into contribs. Guile for 2.x might be somewhat more useful; if there are users who want to script gnubg, they might well want to talk to the GUI. And I could imagine it might be of use for people who want to develop new Gtk+2 apps using Mandrake. On the other hand, I haven't heard anyone complain yet. And everyone who's contacted me about gnubg has just said, cool, it works!; I don't think any of them are interested in the possibility of scripting it. So guile-gtk2 probably isn't all that important either. If someone has a working package lying around, I'd be happy to play with it--but I'd be more interested in getting a full libglade and g*-- 2.x setup so I can show off anjuta to Windows developers who are ready to switch except that they're hooked on MSDev
Re: [Cooker] More on the obsoletes stuff
On Tuesday 22 July 2003 04:17, Olivier Thauvin wrote: Le Mardi 22 Juillet 2003 06:27, Andi Payn a écrit : On Monday 21 July 2003 19:43, you wrote: Le Lundi 21 Juillet 2003 17:44, Andi Payn a écrit : Under rpm 4.0, installing or upgrading a package only checked its obsoletes against the main package name. Now, 4.2 also checks against any virtual names provided by the package. So, with 4.0, two packages that provided and obsoleted the same virtual name wouldn't interfere; now they do. After checking, I am not sure: I've attached the simplest possible packages to demonstrate the problem. 1. rpmbuild -ba dummy1, dummy2-1mdk, and dummy2-2mdk. 2. rpm -Uvh dummy1-1.0-1mdk.noarch.rpm now dummy1 is installed 3. rpm -Uvh dummy2-1.0-1mdk.noarch.rpm now dummy1 and dummy2 are both installed 4. rpm -Uvh dummy2-1.0-2mdk.noarch.rpm now dummy1 is gone; onldummy2 is installed Apparently this is only triggered when upgrading an existing package to a later version (step 4). That's what your test was missing. The obsoletes tag in dummy1 and the provides in dummy2 are unnecessary to trigger the problem, but I put them in to better simulate the situation that seems to turn up in real packages. If you remove the Provides tag from dummy1, the problem goes away. If you remove the Obsoletes tag from dummy2, the problem goes away. If you version the Obsoletes tag so it doesn't match dummy1, the problem goes away. Can I have rpm -q rpm from your system ? rpm-4.2-12mdk I first noticed this behavior with an earlier version of rpm-4.2 (I can't remember which, but I think it was a single digit, -8 or -9 maybe), and it's been unchanged through at least one, possibly two upgrades. Have you tried my dummy packages on another rpm-4.2 system with different results?
Re: [Cooker] More on the obsoletes stuff
On Tuesday 22 July 2003 19:58, Olivier Thauvin wrote: Le Mardi 22 Juillet 2003 04:48, Andi Payn a écrit : On Monday 21 July 2003 18:24, Olivier Thauvin wrote: Le Mardi 22 Juillet 2003 02:41, Andi Payn a écrit : But if there are packages that don't provide %name but do obsolete %name, that's an indication that someone's possibly thought it through correctly and did this for a reason. Am I making myself clear, or just more confusing? Useally you provides and obsoletes the old package (rpmlint warn if not). But someetimes, for somes reason, you must only obsoletes the old packages. I haven't example at time (maybe %libname%major), but I allready found this case. I'm talking about packages that obsolete their _own_ %name. If they also provide their own %name%, this is probably a mistake; if they don't, then those are the examples I'm looking for Remember, the original question that got us off on this long side track: If we're going to lint for packages that obsolete other packages in the distribution (either directly, or through their provides), what should be do with packages that obsolete themselves? So, we were looking for examples of packages that obsolete their self through their own %name, in order to make sure we know why this would occur. We found one package that both provided and obsoleted its own %name (actually, a -devel package that provided and obsoletes %name-devel, but it's the same thing). We agreed that this is probably a mistake. So, now I'm trying to see if there's a package that obsoletes its own %name, but doesn't also provide its own %name. foo neither provides nor obsoletes %name; you have foo and bar. foo provides %name; exactly the same (because foo automatically provides %name whether you specify it or not). foo obsoletes %name; you have only foo, you can keep packages requiring foo (because foo automatically provides foo), but not packages requiring bar. foo provides and obsoletes %name; exactly the same. Right? hum which %name ? I talking about foo providing and/or obsoleting its own %name, foo (either by using Provides: %name or Provides: foo), when bar (which you've already installed) also provides foo. I think I got all four possible cases right. Since provides has no effect, this reduces to two cases. And the only issue that matters is this: If foo obsoletes foo, then if rpm -Uvh foo replaces a package bar which provided foo, it will let you keep packages that depended on foo (that you were able to install because you had bar). If not, those packages will be removed. If I have this right, then the question is, is this useful behavior? If so, we should not flag packages which obsolete themselves. If not, we should.
Re: [Cooker] URPMI --auto-select --auto removed KDE
On Tuesday 22 July 2003 19:38, Paul Misner wrote: This was really odd. I did a urpmi --auto-select --auto, and the listing that follows was the result. I proceeded to urpmi the packages it removed, and they all installed fine. My question is, why did urpmi think it needed to uninstall KDE, and why did it not ask me for permission to remove those packages? Seriously nasty problem, and one that I've not seem before. Is there any information I can send you that would help locate the problem? This is caused by arts obsoleting all of the KDE packages through virtual names. I'm not 100% sure whether it's a bug in RPM that causes all of these packages to be removed, or whether that's appropriate behavior; either way, those obsoletes are probably wrong. To quote the latest post on this (Re: [CHRPM] arts-1.1.2-7mdk from Charles A. Edwards): The arts installation is Still removing kdebase. The problem can be blamed on either on arts.spec Obsoletes Obsoletes: kcpuload = 1.90-11mdk, kdbg = 1.2.5-1mdk, kdeaddons3, kdeadmin3, kdeartwork3, kdebase3, etc or the kdebase Provides which still has it Providing kdebase3 etc. Should not these Only apply for Mandrake releases for which kde3 rpms were avaiable, those were the /opt ones. There should be no need for them for 9.1 or 9.2 builds, don't recall about 9.0
[Cooker] More on the obsoletes stuff
After a bit of experimenting on 9.1 and cooker, I think I've figured out why all these problems are just showing up now, and what to do about it. Under rpm 4.0, installing or upgrading a package only checked its obsoletes against the main package name. Now, 4.2 also checks against any virtual names provided by the package. So, with 4.0, two packages that provided and obsoleted the same virtual name wouldn't interfere; now they do. The new behavior is probably better. But this means that a bunch of old inconsistencies that never caused problems before now have to be taken care of. Also, I think there is a bug in the new behavior: If you install/upgrade two packages at once, and they both obsolete each other, they install without a problem. This should fail. Anyway, here's what to do: 1. Someone should look at my script and make sure I didn't do something stupid and miss some of the problems. Run this script every so often until no more problems are reported. 2. One of the checks on uploading a new package should be to make sure that it's not obsoleted by any other package (an error), and to check whether it obsoletes any existing packages (a warning, because sometimes this is the desired behavior). Is this feasible if one package is in contribs and the other in main? (Or, worse, if one is is plf?) 3. Go through all of the dozen or so problems I've already reported and eliminate them. I've emailed all the relevant maintainers, but if necessary I can go through and patch all the specfiles myself. 4. Come up with a new policy for provides/obsoletes when replacing old packages. Just versioning the obsoletes will solve 95% of the problems. (If gimp-1.2 and gimp1_3-1.3 both said Obsoletes: hackgimp 1.2 instead of Obsoletes: hackgimp everything would work fine.) To solve the other 5%, don't ever copy over obsoletes tags from the previous major version (except where it makes sense, of course). 5. Fix rpm so an install/upgrade fails if two of the packages obsolete each other. The error messages related to this stuff could be a little clearer, and I think urpmi might be getting confused by some of these symptoms, but I think those issues will go away once all the packages are fixed
Re: [Cooker] More on the obsoletes stuff
On Monday 21 July 2003 12:10, Thierry Vignaud wrote: Andi Payn [EMAIL PROTECTED] writes: The new behavior is probably better. But this means that a bunch of old inconsistencies that never caused problems before now have to be taken care of. a new job for distriblint ? That sounds like the right place to put it. Maybe just check to see that no current package obsoletes another current package unless the two conflict? 4. Come up with a new policy for provides/obsoletes when replacing old packages. Just versioning the obsoletes will solve 95% of the problems. (If gimp-1.2 and gimp1_3-1.3 both said Obsoletes: hackgimp 1.2 instead of Obsoletes: hackgimp everything would work fine.) To solve the other 5%, don't ever copy over obsoletes tags from the previous major version (except where it makes sense, of course). Does the fact that you excerpted this quote without comment mean that you agree that this is a good idea?
Re: [Cooker] RedHat trying to beat us at our own game?
On Monday 21 July 2003 13:37, Stefan van der Eijk wrote: Just wondering how OPEN RedHat will be to changes other souls bring in... I'll be keeping an eye on it... could be interesting to get some of MDK's ideas into RHL. Like separate lib packages, urpm, and version numbers with dots? By the way, has anyone downloaded their new beta yet? What version is it? I think that more user participation is going to be especially hard for Redhat, considering the problems they'll have disentangling distro problems from upstream problems. If a GNOME package has a bug, they can't exactly say, not our fault, go talk to Havoc.
Re: [Cooker] RedHat trying to beat us at our own game?
On Monday 21 July 2003 12:20, Buchan Milne wrote: Pierre Jarillon wrote: Hmmm, compare: http://rhl.redhat.com/ to: http://qa.mandrakesoft.com/wiki Well, under dillo, Mandrake looks better, but under elinks, RedHat looks better. Under lynx, they both look nice and plain, but RedHat is cleaner and easier to navigate.
Re: [Cooker] More on the obsoletes stuff
On Monday 21 July 2003 10:51, Charles A Edwards wrote: On Mon, 21 Jul 2003 08:44:23 -0700 Andi Payn [EMAIL PROTECTED] wrote: 4. Come up with a new policy for provides/obsoletes when replacing old packages. Just versioning the obsoletes will solve 95% of the problems. (If gimp-1.2 and gimp1_3-1.3 both said Obsoletes: hackgimp 1.2 instead of Obsoletes: hackgimp everything would work fine.) To solve the other 5%, don't ever copy over obsoletes tags from the previous major version (except where it makes sense, of course). I am wondering if this same is also occurring with Conflicts/Provides. When I uploaded gettext_0.12-0.12.1 each sub pkg carried the tag Conflicts: [foo] %version Provides: [foo] = %version If urpmi/rpmdrake is used to install gettext_0.12 it naturally wants to remove the currently installed gettext-0.11.5, But it also wants to Remove All pkg and children which have a Require for gettext. It is disregarding the Provides for the gettext_0.12 pkgs. If the 0.12 rpms are manually installed the Provides are accepted since --auto-select does not want to remove anything due to failed Depends. I don't think this is the same problem. My guess is that what's happening is this: urpmi sees the conflicts, and decides to remove the gettext packages before trying to install the gettext_0.12 packages. To remove all of those packages, it has to remove everything that requires those packages. So it does so. Then it installs the new packages. If the new packages obsoleted the old ones rather than conflicting with them, then urpmi could just use rpm to upgrade to the new versions, so it wouldn't try to uninstall the old versions first, so all the dependent packages wouldn't get removed. In other words, if I'm right, this is almost the exact opposite problem: instead of being caused by adding unnecessary obsoletes tags, it's caused by omitting necessary obsoletes tags
Re: [Cooker] More on the obsoletes stuff
On Monday 21 July 2003 14:26, Olivier Thauvin wrote: No, maybe you never seen this error: * perl-ming-0.2a-5mdk.i586 (ming-0.2a-5mdk.src.rpm) [2] OBS: obs by perl-ming-0.2a-5mdk.i586 [2] * printman-0.0.1-0.20021202.1mdk.i586 (printman-0.0.1-0.20021202.1mdk.src.rpm) [2] OBS: obs by gnome-cups-manager-0.17-1mdk.i586 [2] OBS mean the package is obsoletes by... Packager which have an old or obsolete package get this warning. But dislint does not expand obsolete to provides. I will fix this. I think this is the whole problem in a nutshell: rpm 4.2 expanded obsoletes to virtual provides, and distriblint didn't. I'm glad the solution is so easy.
Re: [Cooker] More on the obsoletes stuff
On Monday 21 July 2003 16:38, Olivier Thauvin wrote: I just finnish the code fix about this in distlint Great! (I add check, check always more check, it become very slow...), but I discover an interesting things. After test, It report a lot of rpm obsoleting theirself, for example zebra, then i check why. Yes, I should have mentioned this. The first change I made to my script (well, the second; the first was to make it read the list once rather than call urpmf O(n^2) times...) was to take care of this issue. It does seem a bit conceptually weird to me when a package obsoletes itself (wouldn't it make more sense to Obsolete: foo %version?), but since there's no harm done, I decided it was better not to focus only on the handful of packages where there was an actual problem in practice. I have a workaround, do not report when a rpm obsolete itself except when it obsolete it %name (this last case is not normal, a new version obsoletes an older of course). I didn't think about that special case (because I never saw it happen), but that sounds like it should be flagged. Rpm sucks... you allready know that... Yes, but then linux sucks too. For that matter, computers suck All we can do is make it suck less (or move to a shack in Montana and mail out letterbombs).
Re: [Cooker] More on the obsoletes stuff
On Monday 21 July 2003 17:33, Olivier Thauvin wrote: Le Mardi 22 Juillet 2003 01:55, Andi Payn a écrit : I have a workaround, do not report when a rpm obsolete itself except when it obsolete it %name (this last case is not normal, a new version obsoletes an older of course). I didn't think about that special case (because I never saw it happen), but that sounds like it should be flagged. Are you sure: %define TDSVER 7.0 %define name freetds %define release 1mdk %define version 0.61 Summary:An OpenSource implementation of the tubular data stream protocol. Name: %name [...] %package devel # This mean the package will be name freetds-devel [...] Provides: freetds-devel Obsoletes: freetds-devel No comment. The question is, why does freetds-devel provide freetds-devel in the first place? Unless there's some reason that I'm missing, this has to be a mistake. In which case this package should be flagged (even though it doesn't do any harm). Are there any examples where a package obsoletes %name but doesn't also provide %name like this? Meanwhile, I've been thinking about the general use of obsoletes to replace old packages. I need to do some more testing, but I'm not sure it's needed at all with rpm-4.2 In other words, I think that if package foo provides bar, and you install foo, rpm-4.2 removes bar even if foo doesn't also obsolete bar. If I'm right, we could get rid of all of these extra obsoletes, making it much easier (more packages to be changed, but a simpler test to lint for, and no judgement calls to be made). If I'm wrong... well, then never mind.
Re: [Cooker] More on the obsoletes stuff
On Monday 21 July 2003 18:24, Olivier Thauvin wrote: Le Mardi 22 Juillet 2003 02:41, Andi Payn a écrit : Are there any examples where a package obsoletes %name but doesn't also provide %name like this? Yes, I found lot. You should know all rpm since version 4 provides %name = %version-%release without adding a specific provide in spec. Yes; that's why I thought it strange that freetds-devel explicitly provides freetds-devel when it already happens automatically. And just to make sure, packages don't automatically obsolete %name %version-%release or anything like that; the update logic that essentially simulates this is completely separate from the obsoletes logic. Right? Then a package obsoleting his %name always obsoletes this provides. Right; what I was asking was whether there are any packages that obsolete %name, other than cases where they also explicitly provide %name (or where the -devel packages provides %name-devel, etc., as in the freetds case). If a package is providing %name, that's already one tag that's there for no reason (either a mistake, or a packager who doesn't understand the system, or a leftover from years ago). In that case, the logic behind that package's tags is suspect. But if there are packages that don't provide %name but do obsolete %name, that's an indication that someone's possibly thought it through correctly and did this for a reason. Am I making myself clear, or just more confusing? In other words, I think that if package foo provides bar, and you install foo, rpm-4.2 removes bar even if foo doesn't also obsolete bar. No, this was a bug, fix since -7mdk (don't remember exactly, but by fpons), and fixed by RH after RH9.0 released: Ah, that's what I get for reading RH9 docs (And don't the Redhat thought police come after you if you call it 9.0, yelling there is no dot! and beating you with rubber hoses until you confess that the latest linux doesn't mean 2.6.0-test1?) foo provides bar; rpm -Uvh foo you have foo and bar foo obsoletes bar; rpm -Uvh foo, you have only foo, bar was removed foo provides and obsoletes bar; you have only foo, bar was removed, but you can keep packages requiring bar. This makes sense: there are three different behaviors you might want, and this provides a way to get any of them. But I still don't get why a package would provide %name, and the case for obsoleting %name seems pretty uncommon. Let's say that bar provides foo (otherwise, there's no issue at all), and we're now going to rpm -Uvh foo: foo neither provides nor obsoletes %name; you have foo and bar. foo provides %name; exactly the same (because foo automatically provides %name whether you specify it or not). foo obsoletes %name; you have only foo, you can keep packages requiring foo (because foo automatically provides foo), but not packages requiring bar. foo provides and obsoletes %name; exactly the same. Right? So, providing %name never has any effect. Obsoleting %name has an effect if there's another package that provides foo, that the real foo is incompatible with. But, if you've found this lots, does this mean there are lots of packages where this issue comes up? wahou ! I hope you still follow me :) So do I But it's interesting to make a little test, I take basystem (easy to build), and make it wrong: I usually just build dummy packages, so I can test them on every system I have (different versions of rpm and all that) with little chance of breaking anything important Next time, I explain with epoch tag... :) Yes, and while you're at it, tell us how to use a --with flag to rpmbuild to select between obsoleting by version or by epoch (but only if you're building on a weekday, of course).
Re: [Cooker] More on the obsoletes stuff
On Monday 21 July 2003 19:43, you wrote:
Le Lundi 21 Juillet 2003 17:44, Andi Payn a écrit :
Under rpm 4.0, installing or upgrading a package only checked its
obsoletes against the main package name. Now, 4.2 also checks against any
virtual names provided by the package. So, with 4.0, two packages that
provided and obsoleted the same virtual name wouldn't interfere; now they
do.
After checking, I am not sure:
I've attached the simplest possible packages to demonstrate the problem.
1. rpmbuild -ba dummy1, dummy2-1mdk, and dummy2-2mdk.
2. rpm -Uvh dummy1-1.0-1mdk.noarch.rpm
now dummy1 is installed
3. rpm -Uvh dummy2-1.0-1mdk.noarch.rpm
now dummy1 and dummy2 are both installed
4. rpm -Uvh dummy2-1.0-2mdk.noarch.rpm
now dummy1 is gone; onldummy2 is installed
Apparently this is only triggered when upgrading an existing package to a
later version (step 4). That's what your test was missing.
The obsoletes tag in dummy1 and the provides in dummy2 are unnecessary to
trigger the problem, but I put them in to better simulate the situation that
seems to turn up in real packages.
If you remove the Provides tag from dummy1, the problem goes away. If you
remove the Obsoletes tag from dummy2, the problem goes away. If you version
the Obsoletes tag so it doesn't match dummy1, the problem goes away.
Summary: A dummy package for testing
Name: dummy1
Version: 1.0
Release: 1mdk
License: GPL
Group: System/Base
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
Provides: virtual-dummy
Obsoletes: virtual-dummy
BuildArch: noarch
%description
This package contains nothing. It's just there to test rpm features.
%files
%changelog
* Mon Jul 21 2003 andi payn [EMAIL PROTECTED] 1.0-1mdk
- first specfile
Summary: A dummy package for testing
Name: dummy2
Version: 1.0
Release: 1mdk
License: GPL
Group: System/Base
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
Provides: virtual-dummy
Obsoletes: virtual-dummy
BuildArch: noarch
%description
This package contains nothing. It's just there to test rpm features.
%files
%changelog
* Mon Jul 21 2003 andi payn [EMAIL PROTECTED] 1.0-1mdk
- first specfile
Summary: A dummy package for testing
Name: dummy2
Version: 1.0
Release: 2mdk
License: GPL
Group: System/Base
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
Provides: virtual-dummy
Obsoletes: virtual-dummy
BuildArch: noarch
%description
This package contains nothing. It's just there to test rpm features.
%files
%changelog
* Mon Jul 21 2003 andi payn [EMAIL PROTECTED] 1.0-2mdk
- just bumping the version...
* Mon Jul 21 2003 andi payn [EMAIL PROTECTED] 1.0-1mdk
- first specfile
[Cooker] gtkextra and guile for Gtk 2?
In attempting to make a gnubg package, I noticed a few issues: There doesn't appear to be a guile-gtk 2.x package. And, while the equivalent 1.x packages exist, they don't seem to be recognized by gnubg's autoconf. I even tried building some autoconf scripts from scratch following the recommendations, and they don't find either guile-gtk. (For example, guile-gtk.h is placed in /usr/include/libguile-gtk-1.2_0/guile-gtk.h, but guile-config doesn't list that directory, so the file is never found.) The exact same problems turn up with gtkextra. If you link /usr/include/libguile-gtk-1.2_0/guile-gtk.h into /usr/include, that allows guile to be used in gnubg. Should the package (libguile-gtk-1.2_0-devel) include this link, or is there a better way to accomplish this? Anyway, what's the status on these packages? Is someone working on them? Should I try packaging up all the guile stuff for Gtk+ and GNOME 2.x for contribs?
Re: [Cooker] gtkextra and guile for Gtk 2?
On Sunday 20 July 2003 06:03, Abel Cheung wrote: Andi Payn wrote: | I even tried building some autoconf scripts from scratch following the | recommendations, and they don't find either guile-gtk. (For example, | guile-gtk.h is placed in /usr/include/libguile-gtk-1.2_0/guile-gtk.h, but | guile-config doesn't list that directory, so the file is never found.) Is the /libguile-gtk-1.2_0/ subdir invented by packager? I'm not sure. I do know that the only file in that directory is guile-gtk.h, however. | The exact same problems turn up with gtkextra. You mean building gtk2 port of gtkextra? I had it packaged (not submitted because no package need it so far) but it doesn't need guile at all. No, sorry; nothing to do with guile here. I meant that (just as with guile), there is no package for the gtk2 port of gtkextra. If you have an up-to-date package, please upload it. (If you're concerned that no package needs it, well, now we have one: gnubg.) Or I can package it, if you don't want to bother. | If you link /usr/include/libguile-gtk-1.2_0/guile-gtk.h into /usr/include, | that allows guile to be used in gnubg. Should the package | (libguile-gtk-1.2_0-devel) include this link, or is there a better way to | accomplish this? Better patch guile-config to include the aforementioned include dir. On the other hand, if we get the gtk2 port of guile-gtk, then the only package I've seen for which this is a problem will use that instead, so there's really no need to change anything. Thanks.
Re: [Cooker] lm_sensors 2.8.0 is out
On Sunday 20 July 2003 05:46, Guillaume Rousse wrote: Please upgrade lm_sensors and kernel packages. I've been looking at the lm_sensors package, and I think I'm missing something. When I've used this in the past (built from the tarball), the i2c and lm_sensors packages have both built kernel modules that I had to install. But in the Mandrake lm_sensors package, no kernel modules seem to be built. Does this mean that the Mandrake kernel is patched to already include all the modules in the current lm_sensors version, or does it mean that whichever sensors need extra modules just aren't going to work? For example, I've got a Dell PowerEdge 2400, which has three ltc1710 sensors and an smbus-arp controller, as well as a slew of lm75's and eeproms. When I install the RPM (or build the SRPM), everything but the eeproms is useless: the lm75's fail to read because they're disabled, and the ltc1710 and arp fail to read because the kernel modules don't exist. When I build manually from the tarball, everything sort of works (sort of because the lm75's still don't actually read the temperature; I think the BIOS is doing funky things). Since it looks like the i2c package has been progressively better integrated into the kernel, maybe with kernel 2.6 and lm_sensors 2.8 (some of) these troubles will go away? If not, I think there's a problem that has to be fixed (unless it's acceptable that only some sensors are readable--which it might be, because the most common/useful ones usually are).
Re: [Cooker] split lists?
Why is there still an argument going on? The people against the split are saying, I don't see the need, but I guess we could try out a few sublists, if for nothing else then to keep you idiots quiet. The people who want the split are saying, You reactionary running-dog bastards, I demand that we try out a few sublists now! So, what exactly is all the shouting about? Let me summarize what everyone on all sides seems to be saying minus the rhetoric, and see if there's still any substantive disagreement: Step 1: Create a few sublists. Accept that this may not be the final breakdown, but a good starting point is Warly's suggestion (install tools, config tools, and GUI) plus Buchan's server-specific list. Step 2: For now, forward all of the lists to the master list cooker (munging reply-to if necessary), so people who don't do anything will continue to see everything. Alternatively, provide an easy way to subscribe to all lists at once (a message sent to everyone on the list that, if replied to, will subscribe you to the other lists). Step 3: Leave bugzilla alone, and everything else. Step 4: See how it goes.
Re: [Cooker] So, is someone going to file a bug against...
It was French linguists (back in the pre-Chomsky dark ages) who first showed what a silly idea this kind of system is--in words not much different from Thierry's. And every Frenchman that I talk to thinks the whole thing is stupid. And yet, France is the only country in the world that still attempts to legally enforce some bizarre idea of correct language change. So, why is this system still in place? Why hasn't someone run for government specifically with the idea of getting rid of it? Or, just ignore the whole thing, use the wrong words without a second thought, and don't argue in front of the rest of the world lest the Quebecois will start to get the idea that they're as good as you It may sound a bit odd for an American to throw stones, since the US has more stupid laws and policies than all of Europe put together--but that's just the point: We expect you to be more rational than us, and it's always disappointing to see you being as stupid and jingoistic as Americans--or, worse, as whinily accepting as Americans of stupid and jingoistic policies that you actually hate.
Re: [Cooker] So, is someone going to file a bug against...
On Friday 18 July 2003 17:18, Austin wrote: So while Quebec may not have an Academie Francaise, they work their asses off trying to prevent engligh encroachment... and IT WORKS! I have many friends from Quebec who are in college and can barely speak English, and cannot write it at all. Not that this is a good thing... my point is just that it's working (to a degree). Well, I have many friends from America who are college graduates and can barely speak or write English, even though it's usually their first language (and often their only language, unless you count yo, like, hae-blo un pik-keeto es-spaniel, like, y'know?). So, all you have to do is pick up the education policies of Reagan/Bush/Clinton/Bush America and you'll get the same effect. Given Alberta's gung-ho emulation of America, they'll probably surpass Quebec in English illiteracy soon
Re: [Cooker] Re: [Contrib-Rpm] sticky-notes-applet-1.0.11-1mdk - files conflict
When I first submitted sticky-notes-applet, I mentioned that it was almost definitely going to be included in gnome at some point, and therefore in the Mandrake gnome-applets package. So we were going to have to obsolete it at that point. But at this point, weeks or months later, how likely is anyone to remember that? Hence this confusion. When could have been even worse if the name of the applet had been changed when it was accepted into the main GNOME distribution (as when gnome-sensors becoming gsensors). Then there'd be no file conflict, and no indication that there was a problem at all. Is there a good way to make such notes stick so problems don't come up later? For example, does it make sense to put them in the package description: This applet will become part of GNOME in the future, at which point this package will become obsolete or something like that? Would it be acceptable to have such a description in a package in the 9.2 release? (By the way, if I knew this would happen well before Mandrake 9.2, I probably wouldn't have submitted it at all, and I'm sure Austin wouldn't have uploaded it--but there was no way of knowing that.) On Wednesday 16 July 2003 02:03, Frederic Crozat wrote: On Tue, 15 Jul 2003 13:05:24 -0400, Austin wrote: On 2003.07.15 11:30, Frederic Crozat wrote: On Tue, 15 Jul 2003 17:09:43 +, FACORAT Fabrice wrote: Le ven 11/07/2003 à 17:01, Austin Acton a écrit : [Contrib-RPM] --=-=-= Name: sticky-notes-applet Relocations: (not relocateable) Version : 1.0.11Vendor: MandrakeSoft Release : 1mdk Build Date: Fri Jul 11 18:29:35 2003 file /usr/lib/stickynotes_applet from install of sticky-notes-applet-1.0.11-1mdk conflicts with file from package gnome-applets-2.3.5-1mdk Ok, I'll obsolete it.. No no, don't have to obsolete it. I shoudln't have even uploaded it. Rpmctl seems to be broken so I can't remove it. Will fix. If people already installed it on their system, we must obsolete it otherwise gnome-applets will not be able to be upgraded..
Re: [Cooker] For 9.2 - automatic update - suggestion
Are there enough rsync sources that we can recommend that everyone use one whenever possible? Because that would solve most of the problems with massive downloads of hdlist files, etc
Re: [Cooker] For 9.2 - automatic update notification
On Wednesday 16 July 2003 10:24, Ben Reser wrote: On Wed, Jul 16, 2003 at 07:01:06PM +0200, Buchan Milne wrote: The problem with doing this interactively is how? fpons suggested putting MandrakeUpdate on xinit.d... That assumes the user logs in and out of X on a regular basis. So let's say we put something on a cron that looks for updates, pops up and says hey there are updates. Which user should we display that for? All users in a special group. At low security, this is everyone. At medium security, this is the msec admin. At high security, or expert install, whoever's installing needs to know what a group is and deal with it. This would be roughly equivalent to the system on Windows XP (except when installing on an NT/2K domain, where it gets more complicated and essentially doesn't work). My mother and sister share a computer, and they see the fact that whichever one of them is logged in can see and install the updates as a good thing. This assumes users are logging in and out of X on a regular basis. On many of my machines I don't for months at a time... But you are capable of writing a cron job to do it for you, which is why you don't even need such a tool. There are many users who are not capable of writing a cron job, and who also stay logged in for weeks on end. The fact that you can do just this--that you almost never have to log out, much less reboot--is one of the selling points for converting to linux. If we tell people that they have to log out and back in periodically to check for updates, that won't sound good: Oh, so linux is just like Windows, they just try to hide it better. Buchan: Remember that most of the time it should be running as a normal user, and thus should not run 'urpmi.update' or anything else that requires elevated priveleges. The automated update system is useless if there's nothing automatically running urpmi.update every so often. Maybe this should be installed as a weekly cron job for users who specify an always on connection, as an ifup script (that does nothing unless it's been more than, e.g., 6 days since last time) for those who specify a dialup connection? Whatever, it should be almost completely invisible to novice users. Buchan: Has no-one on this list installed Redhat recently? Ben: Why would I want to? To steal their best ideas--and, more importantly, to avoid their worst mistakes. As for how to download and install packages, it might be nice to pre-download them (as XP does). (What if there are multiple users? Provide a directory under /var/tmp or something which all users have write access to, and download them there.) However, it's probably easier and safer to have MandrakeUpdate download the packages on demand (as root).
Re: [Cooker] Bug in Mandrake package install system?
On Thursday 17 July 2003 11:59, Olof Bjarnason wrote: Thanks for your advice, although I have some more questions :) # Is this a bug? #No. If not a bug - what is it? Should the combination of actions which I took not lead to installation of a custom rpm? This implies there are 'special' packages, or Mandrake-packages, in which case at least I would favor a notification upon clicking on such a foreign package. For example, it would be helpful if Mandrake tells me Warning: Non-Mandrake package. Install manually with urpmi when I click on my 'abc.rpm'. The urpmi tools are not about packages, but about urpm sources, which are repositories of packages. So, the short answer is: You must build a custom urpm source containing your custom packages before you can use urpmi to install those packages. Just copying the rpm's into a directory is not enough. If you want to go through the experience of building your own source, there is documentation for that, but it's not for beginners. If all you want to do is get your custom packages installed, use rpm instead of urpm. (You may also want to submit the packages to contribs, if you think others might want them.) What's the point of all of this? It's so that we can have standard sources for upgrades and contributed packages which automatically keep track of relationships. So when I try urpmi foo it'll automatically know that it has to download and install bar (which foo requires) and uninstall baz (which foo obsoletes) with no extra work on my part.
Re: dealing with bug reports from stable releases (was Re: [Cooker] kernel 2.4.21-0.13 has no APM?)
On Tuesday 15 July 2003 12:02, Gary Lawrence Murphy wrote: I suppose -- people /still/ use Windows? Amazing ;) I'm sure Buchan will explain why samba is going to be necessary for Windows to finally die--but even after that happens, samba may well survive. SMB/CIFS, when done right, is a good filesharing system. The only real problem with it is that all of Microsoft's implementations so far stink--but samba 3 does not stink. Samba is not only useful for transitioning LANs from Windows to linux, it's also useful for all kinds of multi-platform LANs. I can't think of another filesharing system that runs on so many *nix platforms that doesn't block in the kernel on network reads, handles user-level shares easily (with nice GUIs, even), allows hierarchical networks, can use LDAP or various other techniques for authentication, etc. And that works on every version of Windows, and Mac OS X, and (with cheap add-on software) MacOS 9.
Re: [Cooker] xine-lib-compat
On Monday 07 July 2003 23:51, Götz Waschk wrote: Am Montag, 7. Juli 2003, 18:05:42 Uhr MET, schrieb Andi Payn: 2. xine-lib-compat-plugins-0.9.13-11mdk vs. xine-plugins-1-0.beta12.5mdk These both provide and obsolete xine-xv, xine-gl, and xine-oss. The result is that, if you have both installed, upgrading to a new version of xine-plugins via rpm fails, while upgrading it via urpmi removes xine-lib-compat-plugins and all codecs that haven't been ported to 1.0 yet (which includes divx4). Solution: xine-lib-compat-plugins should neither provide nor obsolete xine-xv, xine-gl, and xine-oss (any package that requires those should be pulling in the current xine-plugins, right?). No, that's not the solution. The right thing would be to remove xine-lib-compat, as it's obsolete. I tried that but I don't have the right permissions for the rpmctl command on main. This is exactly what I wanted someone besides me (ideally the package maintainers) to look at each one of the problems: I was pretty sure I'd be wrong about some of them (and a few, as I mentioned, I had no idea what needed to be done). However, some of the plugins still require xine-lib-compat-plugins. I haven't checked, so maybe all of the affected plugins are PLF-only, but they include pretty important things (like the divx4 codec). Maybe these all just need to be recompiled against xine-plugins, but it would be good to know that (and know that it was going to be done) before getting rid of the compat libs. Also, kxine and sinek require the compat libs. Since neither of these is in Cooker, maybe someone's decided they're no longer useful enough to update. If that's true, for people upgrading from 9.1 to Cooker (or 9.2), would it be useful to have xine-plugins explictly Conflict them (= their last version)?
Re: [Cooker] 13 mutual-obsoleting problems
On Wednesday 09 July 2003 03:53, Thierry Vignaud wrote: Andi Payn [EMAIL PROTECTED] writes: 8. libalsa-oss0-devel-0.9.0-0.5rc1mdk vs. libalsa2-devel-0.9.2-5mdk ... argh. i did not think about it when creating libalsa-oss0 spec file from libalsa2 one :-( thanks, fixing in progress Cool, one more off the list. Would it be useful to run this script regularly? I can add it to my daily urpmi.update cronjob and post updates everytime something interesting shows up if it would be of benefit.
Re: [Cooker] split lists?
Buchan Milne wrote: There are some topics I haven't brought up on cooker, that I would like to discuss with other cookers, but since it is quite specialised (regarding default ACLs in openldap, kerberos, samba in conjunction) I don't really feel comfortable spamming the cookers who want to discuss latest KDE or similar topics. I don't see why you shouldn't bring these things up. With a proper subject (e.g., Regarding default ACLs in openldap, kerberos, samba in conjunction), people who aren't interested would know to skip it. I'll bet for 90% of the messages on cooker, the majority of the readers skip it. And that's fine. Also, there are already plenty of focused discussions going on all the time on the current list. I don't think the KDE Galaxy bugs discussion before 9.1, the libtool-1.5 discussion last week, or this discussion have gotten short shrift because they were buried among the rest of the cooker traffic
Re: [Cooker] Licensing questions
Buchan Milne wrote: I may have taken (anything non-commercial) in your paragraph to apply to redistribution... Yes, it's my fault for not being clear enough. At present the OSI requirements are probably the best test for Mandrake, since there isn't a comprehensive policy (as Debian has). It would be a good idea to mention this in the contribution instructions. In fact, it would give Mandrake a comprehensive policy in one line: Unless otherwise specified, Mandrake distributes only software that unambiguously conforms to the OSD, is OSI-certified, and/or uses one of the following licenses: Or, more simply, Mandrake distributes open source software, as defined by the OSI. If that, or something like it, is the (de facto) Mandrake policy, then that answers all of my questions. I could clarify that I was talking about non-modifiable meaning patches must be kept separate (see OSD #4) vs. non-modifiable meaning patches are not allowed, etc., but that's all irrelevant. As for shareware: Shareware means software that you have to pay to use. Not necessarily. Shareware typically means that under certain conditions (non-commercial use, trial period) you may ue the software without paying for it, but under other conditions (commecial use, extended use etc) you may either not use it, or must pay. As a former member of the Association of Shareware Professionals, I always used their definition: Shareware is not a type of software, or a distribution method, but a marketing method. A shareware program is a functioning evaluation version of a program which you can try out to make sure that it meets your needs before buying it In other words, shareware is commercial, non-free (neither free speech nor free beer) software. Just like Windows or Office or Civilization. The only difference is that you can evaluate it without paying for it; you still have to pay if you decide to keep and use it. That's what makes it shareware. Shareware, like any other commercial software, may have any exemptions the developer wants--free for non-commercial use, free for academic use, etc.--but these are entirely separate from whether or not it's shareware. IIRC, SGI used to let universities copy Irix for free (of course you had to buy/borrow/whatever Indy's to run it on...), but that didn't mean it wasn't a commercial product. Most freeware allows redistribution of binaries commercially, which is why I would consider this shareware as opposed to freeware. From the same file: Like freeware, shareware usually allows non-commercial distribution: You can download shareware software from BBS's or the Internet, or copy it from a friend or a users' groups. Like freeware, shareware also often allows commercial distribution: You may find shareware software on a CD you buy, or included with a book or magazine. However, buying that CD, book, or magazine does not mean that you have bought the software In other words, both shareware and freeware often allow unrestricted commercial distribution, but they may restrict commercial distribution, or not allow it at all. The only difference is that freeware is free to use, shareware is not. And, by the way, from Frodo's contact page: Frodo is _not_ a shareware program, but I won't reject any gifts.
Re: [Cooker] split lists?
On Monday 07 July 2003 08:43, Buchan Milne wrote: Michael Scherer wrote: On Monday 07 July 2003 14:46, Guillaume Cottenceau wrote: Even if we can categorise by looking at the subject, we lose time to read the subject. And some people lose time just by receiving the mail (those on tight bandwidth for example). OK, that's a good point. As long as there were a one-step way to subscribe to all of the mailing lists, there'd be no added hardship for Guillaume, me, or anyone else who still wanted to see everything. So why not
Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL, gimp, gimp1_3
For some reason, I haven't seen Thierry's message yet, so I'll reply to Abel's reply to it On Monday 07 July 2003 14:56, R.I.P. Deaddog wrote: Thierry Vignaud wrote: |Given that gimp1_3 obsoletes gimp-data-min, and gimp provides |gimp-data-min, if rpm -U gimp1_3 doesn't want to uninstall gimp, I |think that would be a bug in RPM? | | they both provides/obsoletes it, so there's no bug there. OK, if RPM is working properly, if you install them both at the same time, it will install both--but if you have one, installing or upgrading the other will uninstall the first. And that is exactly the behavior I'm seeing. Worse, once you have the two installed, if a new 1.2 package comes out without a new 1.3, or vice-versa, upgrading will remove the other; you'll have to wait until new versions of both packages are available to upgrade properly. This is a bit unintuitive, to put it mildly. And I think the gimp-data-min shouldn't be obsoleted/provided by gimp1_3, since this is an really old artifact from 1.0-1.2 days. If gimp-data-min package still exist for now, it won't conflict with gimp1_3, so there's not much point to provide/obsolete gimp-data-min in gimp1_3. OK, that would solve the problem just as well, and it's easier. But, is it too late to remove gimp-data-min from gimp1_3 when it was provided by the gimp1_3 package in 9.1 contribs? A quick urpmf --media main-cooker,contrib-cooker --provides |grep gimp-data-min shows nothing relying on this; is that a good enough test to be sure it's safe, or do we also have to make sure that non-Mandrake-provided packages (plf, nexedi, whatever) don't need it? [about hackgimp being provided and obsoleted by both] | we cannot change the past, only the future, so here's the hackgimp | definition. This is true, for gimp 1.2. But for 1.3, I guess we don't need to provide/obsolete hackgimp again. Again, is it ok to remove hackgimp now when it was already in the 9.1 release of gimp1_3? (The same test as above shows nothing in Cooker requires hackgimp either.) | it would just be easier if you send me the spec files for my packages OK, done.
[Cooker] Contrib package: frodo-4.2-0.20030707.1mdk.src.rpm (now GPL'd)
Forget all the discussion; I heard back from Christian Bauer (the author) that he's already got a GPL'd version in CVS. So, here is the GPL'd version of Frodo. The final 4.2 release may be a good while off, but the only substantive changes from this version will probably be the docs. So, here it is. I've noticed that some emulators are in Mandrake, some are in PLF; what's the rule here? If Frodo is not appropriate for Mandrake, let me know and I'll submit it to PLF instead. From the package description: Frodo is a free, portable Commodore 64 emulator that runs on a variety of platforms, with a focus on the exact reproduction of special graphical effects possible on the C64. Frodo comes in three flavours: The normal Frodo with a line-based emulation, the improved line-based emulation Frodo PC, and the single-cycle emulation Frodo SC that is slower but far more compatible.
[Cooker] Uploading question
OK, let me make sure I have the procedure straight: If I'm submitting a new contribution, I upload the SRPM to incoming, and send an email to [EMAIL PROTECTED] and [EMAIL PROTECTED] If I'm submitting a change to an existing package, I email the specfile to the packager, and send an email to cooker. (So the new gimp specs go to Thierry Vignaud.) If I'm submitting a change to an existing package, and the packager is Mandrake Linux Team http://www.mandrakeexpert.com (e.g., libsigc++1.2), what do I do with the specfile? Mail it to the last name on the changelog? Upload it to incoming? Both?
[Cooker] 13 mutual-obsoleting problems
On Friday, I posted a list of provides-obsoletes conflicts in the current Cooker. And, while there seemed to be lots of interest in the script I wrote to generate the list, there seems to be much less in the results. But many of the conflicts that arose need to be fixed. The symptom is this: If two packages both provide and obsolete the same virtual package name, then they can only coexist as long as you install both together, and always upgrade the two together. If you install one first, then the other, the first gets uninstalled. And if you have both installed, then try to upgrade just one, the other gets uninstalled. (If there's are dependencies involved, things get more complicated--e.g., installing libfnlib0-devel will try to uninstall libfnlib0, which it requires, so the whole operation will fail--but it never works out.) To test this yourself: 1. Take a clean, minimal cooker install (or 9.1, but then you have to go through the whole rpm/urpmi upgrade, which is a hassle in itself). 2. urpmi gimp gimp1_3. This should work. 3. Remove all gimp packages. 4. urpmi gimp. This should work. 5. urpmi gimp1_3. It works, and now gimp is uninstalled. 6. urpmi gimp. It works, and now gimp1_3 is uninstalled. For real fun, try this with a whole chain of dependencies (e.g., urpmi ggv). Or try installing older versions of gimp and gimp1_3 and then upgrading one or the other vs. upgrading both at the same time. The three conflicts that triggered this whole discussion (gimp vs. gimp1_3, libsigc++1.0 vs. libsigc++1.2, and libmysql12 vs. libmysql10) seem to be on the way to a solution. But there are at least a dozen more that need to be investigated. If nobody else is willing to look these over, I'll be happy to do the research and experimentation and talking with the relevant package maintainers and come up with fixed specfiles. But I have the feeling that something this pervasive should probably have the input of more than a single outsider. Especially because, in a few cases, I'm not sure I know the right solution. 1. libfnlib0-0.5-3mdk vs. libfnlib0-devel-0.5-3mdk Both provide and obsolete Fnlib. If you install both together, it's fine--but if you have libfnlib0 installed, and try to install libfnlib0-devel later, it tries to uninstall libfnlib0, so the install fails. Solution: libfnlib0-devel should neither provide nor obsolete Fnlib. 2. xine-lib-compat-plugins-0.9.13-11mdk vs. xine-plugins-1-0.beta12.5mdk These both provide and obsolete xine-xv, xine-gl, and xine-oss. The result is that, if you have both installed, upgrading to a new version of xine-plugins via rpm fails, while upgrading it via urpmi removes xine-lib-compat-plugins and all codecs that haven't been ported to 1.0 yet (which includes divx4). Solution: xine-lib-compat-plugins should neither provide nor obsolete xine-xv, xine-gl, and xine-oss (any package that requires those should be pulling in the current xine-plugins, right?). 3. apache-conf-2.0.46-2mdk vs. apache2-common-2.0.46-5mdk apache-conf obsoletes apache-common, which is provided by apache2-common. Is this right? The whole apache/apache2-coexistence thing gives me headaches; all I know that it that it works on my installed 9.1 servers, and for that I'm eternally grateful and amazed Solution: ??? (may not be a problem) 4. php-cgi-4.3.2-6mdk vs. php-cli-4.3.2-6mdk vs. apache2-mod_php-2.0.46_4.3.2-3mdk vs. mod_php-4.3.2-1mdk All four provide and obsolete php430 (there are also conflicts with php and php3). This seems odd conceptually. And, while they all have to be upgraded in sync (since they all require an exact version of libphp_common432), if you have some of these installed and want to add another one, it fails. (For example, let's say you have a standard server setup, without php-cli, and decide you want php-cli too. You can't install it.) Solution: None of these should provide php430 or php3; they can all obsolete php430 and php3. Those that provide php can continue to do so, but they should only obsolete php %version. 5. linuxdoc-tools-0.9.20-4mdk vs. docbook-utils-0.6.13-3mdk vs. openjade-1.3.1-16mdk All three packages provide sgml-tools. The first two also obsolete sgml-tools. I don't know how these are all supposed to interact, or what the virtual package name sgml-tools represents (it seems to be required only by kdevelop). I suspect there's a problem here, but I don't know. Solution: ??? (may not be a problem?) 6. openssh-askpass-3.6.1p2-4mdk vs. openssh-askpass-gnome-3.6.1p2-4mdk Both provide and obsolete ssh-extras. While these have to be upgraded in sync if you have them both, there's a problem if you only have openssh-askpass and try to add openssh-askpass-gnome. I'm not sure what ssh-extras is supposed to represent, but it probably belongs in only one of these two packages. Solution: openssh-askpass-gnome should not provide or obsolete ssh-extras? Or maybe it should not provide ssh-extras,
Re: [Cooker] Licensing questions
I should know better than to tie a general question to a specific one, as it always confuses people, but I did it again anyway Let me jump to the end first: Buchan Milne wrote: Andi Payn wrote: ... and even if contrib allowed non-free software, Mandrakesoft sells copies of Mandrake including contrib for more than $5, violating the license agreement. That was my main question, actually: Does Mandrake sell contrib CDs. Thanks for reading my mind and answering my question, even though I apparently forgot to ask it! (Somehow I deleted the paragraph about this before sending.) Regardless of anything else, that in itself means that Frodo isn't appropriate. 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). So there are restrictions on distribution of non-modified packages. This violates the first requirement for OSI's open-source definition: http://www.opensource.org/docs/definition.php Where in that paragraph did you see any restrictions on distribution of non-modified packages? Now, the $5 rule that appears later may well be a violation of OSI rule 1 or FSF freedom 2, but I want to make sure that this is you replying out of order, not me missing something vital. But you can't distributed a modified version of Frodo itself. This is the question I was most interested in. Given a package with a similar license, but without the $5 rule--in particular, if you were allowed to distribute unmodified source and binaries freely (at any charge), and you were also allowed to use any part of the source code (or binary, where that makes sense) in any other work, and you were allowed to include it as part of an aggregate product, but you were not allowed to distribute a modified version of the original, would that be (according to Mandrake) open source/free/acceptable? (Since IANAL either, I don't quite know how you distinguish between using pieces of the source in a different project vs. distributing a modified version of the original project. Which is a good reason not to try to write your own restrictions that prevent one use and not the other. And yet, developers try anyway.) Is this appropriate for contribs? No, it's not free software (it seems more like shareware), Shareware means software that you have to pay to use. You don't have to pay to use Frodo. You don't have to pay to distribute it. You don't have to pay to get or distribute the source code. You don't have to pay to pay to use pieces of the source code in other open source projects. So I don't see how this is anything like shareware. You do need permission to use pieces of the source code in commercial works, but then the same is true of anything under the GPL.
Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL, gimp, gimp1_3
On Sunday 06 July 2003 11:13, Thierry Vignaud wrote: Andi Payn [EMAIL PROTECTED] writes: As I mentioned in my last email, there are problems in at least these three pairs of packages that prevent the old and new versions from coexisting, even though this wasn't true with recent versions: libsigc++1.0-devel and libsigc++1.2-devel; libmysql10 and libmysql12; and gimp and gimp1_3. i've no problem in having both gimp-1.2 and gimp1_3-1.3 installed at the same moment Do you have the latest versions of gimp, gimp1_3, and rpm? I retested by taking a stock 9.1 machine, urpmi'ng enough of cooker to the point where I could install the current versions of gimp and gimp1_3, then upgrading gimp, then upgrading gimp1_3, and it wanted to uninstall gimp. Given that gimp1_3 obsoletes gimp-data-min, and gimp provides gimp-data-min, if rpm -U gimp1_3 doesn't want to uninstall gimp, I think that would be a bug in RPM? By the way, gimp-1.2.5 provides hackgimp. I don't think this is right, is it? of course it is: compatibility with previous distros when we had both stable gimp-1.0 and development hackgimp-1.1.x which became the new gimp-1.2.0 But this is better served by having it obsolete hackgimp 1.2, rather than providing hackgimp. The main difference between the two lies in other packages' requirements. If gimp-1.2 provides hackgimp, then other packages can depend on hackgimp when they mean gimp = 1.1. I don't think this is a good thing. For one, it pretty much fixes the definition of hackgimp to be gimp = 1.1 forever (or at least until 1.4 comes out). For another, it's a bit weird conceptually for hackgimp to mean the old 1.1 development tree rather than the current development tree. And of course it means that the hackgimp name is no longer available for 1.3, 1.5, 1.9, etc. (although that may not be a problem if the new gimp1_3-style names are preferred). but when do you upload those fixed packages (at least those belonging to contribs) ? I already uploaded the .spec files, as I explained in the previous message. I realize that the cooker submission instructions say to upload the .src.rpm. However, I was told before that when I'm uploading a large package and the only change from the existing version is the specfile it's better to just upload the specfile. If that's wrong, I can upload the .src.rpm files as well.
[Cooker] The python-urpm idea...
I suggested before either porting urpm.pm to python or writing a wrapper around it. With python-perlmodule, this should be unnecessary. Except that (especially for interactive sessions) it's a little harder to introspect perl data than native python data. For example, calling help() on any kind of perl object fails. Also, which you can index or iterate perl hashes and arrays, printing them directly just gives you something like perl pkg=HASH(0x80728f0) rather than anything meaningful. And dir() generally gives the perlmodule methods, rather than the underlying perl methods (just like calling dir() on anything with a custom __getattr__). To play with it yoelp(Perl) help(perlmod) urself, try this: from perlmod import Perl urpm = Perl.urpm() urpm.read_config() After this, you can make pretty much the same calls on urpm (and anything you get returned from it) as you could in perl after: require urpm; my $urpm = new urpm; $urpm-read_config(); Or, with perl-Inline-Python, you could write a simple perl wrapper around your python code instead (but there's no interactive interpreter this way, of course): require urpm; use Inline Python = 'END'; def DoPythonStuff(urpm): ... END my $urpm = new urpm; DoPythonStuff(urpm); (If anyone wants to play with perlmodule and/or perl-Inline-Python before they appears in contribs, let me know and I'll make RPMs available somewhere else.) So, writing a wrapper might still be useful, but is not necessary--so I won't bother unless anyone else really wants it. (Even better--but a much larger job--would be a tool and/or extension to perlmodule that automatically generated wrappers around perl modules, converting pod into docstrings, maybe even providing dir transparently)
[Cooker] Licensing questions
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. Is this appropriate for contribs? (I've enclosed the complete license at the end). And, if so, what License tag should the RPM carry? And this leads to the general question: what to put in the License tags if nothing in the official list fits (that is, if rpmlint complains), but the package should be compatible with Mandrake anyway? Here are some common cases: * Artistic-or-GPL (very common on perl modules): you can redistribute it in whole or in part under Artistic, GPL, or Artistic-or-GPL. * Embedded-variant Artistic License (usually on perl modules written by academic types): Artistic, but with the extra no overt attempt is made to make this Package's interfaces visible to the end user of a non-compatible larger work clause. no overt attempt is made to make this Package's interfaces visible to the end user of the commercial distribution * BSD-or-GPL (common on small libraries): like Aristic-or-GPL, or sometimes slightly different--the package as-is is under BSD (or X11 or MIT), but you can relicense any part of it under GPL and/or LGPL to use in a larger work. * BSD-like and MIT-like licenses (common all over the place): A license which is functionally equivalent to BSD or MIT but worded differently (which may even make reference to its intended equivalence to BSD or MIT). * Sloppily-written licenses that make no sense (common on programs that originated as shareware or closed-source freeware, and on small libraries that originated in the Windows world): My favorite example is, I retain the copyright, but you can do whatever you want with the code anyway, with no silly GPL or BSD restrictions. No BSD restrictions is probably supposed to mean MIT-like, but (as the author of the quoted license acknowledged) the actual effect is that you can make an exact copy of the source and relicense it any way you want (including releasing it to the public domain). What do we call such a thing? Or, is it nicer to the author to give it an MIT-or-GPL license or something like that? I think I've seen at least BSD-like and Artistic-or-GPL on contrib packages, but I'm not sure (there doesn't seem to be a urpmf --license or anything equivalent...). And, in the case of Artistic-or-GPL and the simple BSD-or-GPL, should we put the one-liner or clause in a license file and refer to common-licenses for the Artistic, GPL, BSD, etc.? (Usually, Artistic-or-GPL packages have a license file that has the one-liner plus the Artistic license, then the GPL license in a separate file--or everything in one file. The same goes for BSD-or-GPL 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.
Re: [Cooker] Contrib package: libsigc++1.0-1.0.4-6mdk
On Tuesday 01 July 2003 21:03, Austin wrote: On 2003.07.01 14:04, Andi Payn wrote: The current versions of libsigc++1.0 and libsigc++1.2 can't coexist. This means that you can't have both 1.x and 2.x versions of gtk--, gnome--, and glade--. But there's no good reason that they shouldn't be able to; it's just an artifact of the packaging. And there are plenty of good reasons to want both around. With a few minor changes to the 1.0 version, I was able to make them coexist. Well, if gtk1/2, gnome1/2, glade1/2, gtkmm1/2, gnomemm1/2, etc, etc, were all taken care of by only one person, this might not happen. But when three or four people try to put these packages together, weird things happen. Well, it'd be a lot for one person to take care of, and it's much more important for gtk (which is used by pretty much everyone) to be stable than, say, gnomemm devel packages, so I can understand why it's split among three or four people. In other words, this is exactly the kind of thing that we should expect to be caught by outsiders like me By the way, I should have mentioned that in this case, unlike most other packages, it's possible and desirable for the -devel packages to coexist as well. Plus, I'm not sure I fixed this properly; the actual problem seems to be that the 1.2 packages are not just providing, but also obsoleting (regardless of version), the old-fashioned name libsigc++-devel, so the fix really should be to 1.2, not 1.0. Also, I think the same problem exists in other packages. Both libmysql12 and libmysql10 provide and obsolete MySQL-Shared; both gimp1_3 and gimp provide and obsolete gimp-data-min; etc., in every case without regard to version, so these packages that coexisted a month ago no longer can. Maybe someone needs to go through the whole slew of packages and look for incorrect obsoletes tags? Or maybe some recent change in the process is behind this problem and needs to be fixed? If this is yet another artifact of the big changeover that will go away automagically long before 9.2, then I can live with keeping the old packages, modifying the specfiles locally, or doing --nodeps hackery until then. Meanwhile, I'd like to know whether this is a known problem, or whether I should submit bugs for each instance that I find? (Although it may be just as easy to submit fixed specfiles instead) Seems odd that Mandrake would like to be a development platform, yet so many important developer tools are in contribs and often broken or outdated: eric, pyqt, gnomemm2... Presumably these are in contribs because not many developers demand them. Of course this may be circular--maybe if they were in main, and well-supported, there would be more pyqt and gnomemm developers using Mandrake, so there would be more demand, etc., but I suspect this isn't the case. Mandrake is being used by many developers today, and gnomemm isn't as popular as its adherents might wish
[Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL, gimp, gimp1_3
As I mentioned in my last email, there are problems in at least these three pairs of packages that prevent the old and new versions from coexisting, even though this wasn't true with recent versions: libsigc++1.0-devel and libsigc++1.2-devel; libmysql10 and libmysql12; and gimp and gimp1_3. In all three cases, the problem is that both package both provide and obsolete the same virtual package name, so the best solution seems to be to remove the obsoletes tag. For gimp and libsigc++, because both packages are current, I fixed both. For MySQL, because the old version is no longer in cooker, I only fixed the new version. Presumably, anyone who doesn't already have libmysql10 probably doesn't need it. However, I haven't checked to make sure nothing current depends on it. If something does, it obviously needs to be reinstated in the current repository; if nothing does, then maybe my fix isn't necessary. By the way, gimp-1.2.5 provides hackgimp. I don't think this is right, is it? I can see why it might want to obsolete old versions of hackgimp, so I left the Obsoletes: hackgimp, but added a %version-%release in. I also changed the corresponding Obsoletes tag in gimp1_3. This means that users will have to upgrade both to upgrade either. Since some of these are large packages, and in every case only the specfile has been changed, I only uploaded the specfiles: * libsigc++1.0.spec (libsigc++1.0-1.0.4-7mdk.src.rpm) * libsigc++1.2.spec (libsigc++1.2-1.2.5-2mdk.src.rpm) * MySQL.spec (MySQL-4.0.13-3mdk.src.rpm) * gimp.spec (gimp-1.2.5-3mdk.src.rpm) * gimp1_3.spec (gimp1_3-1.3.14-3mdk.src.rpm) Note the name change from libsigc++-1.0 to libsigc++1.0 (to correspond with 1.2). The binary packages will have a similar name change (and libsigc++-examples will become libsigc++1.0-examples). Also note the fact that it's 2 releases later than the one in the repository, because I uploaded a -6mdk earlier in the week. Feel free to disregard the earlier one, and renumber this to -6 if you want.
[Cooker] That obsoletes thing...
I wrote a quick python hack to look for any current packages that obsolete any
other current package. I've included it at the end of this email.
Unfortunately, I think it would take just about forever for me to run it
(~5000 urpmf calls). Anyone who can run it faster, I'll be your best friend
and love you forever and ever and all that stuff
You'll probably have to change line 6 (where I set urpmflags to select the
right media), but that's about it. Oh, and ignore the tmpnam warnings;
there's no other good alternative without python-expect or -pexpect. Just
don't run two copies at once.
Also, I have a few questions:
1. Is there a faster way to do this than running urpmf ~5000 times?
2. Does running urpmf ~5000 times go out to the internet ~5000 times?
3. Would it help if I did this in perl (because we have a perl-URPM but not a
python-URPM)?
4. Would anyone besides me want a python-URPM? (This would obviously take some
time, but I'd be happy to look into it.)
5. Is there actually no python-expect or python-pexpect? Would anyone besides
me want it? (This would take a few minutes.)
6. While I'm at it, does anyone want any other python packages? For my own
use, I've packaged up
python-{rational,cRat,fpconst,indices,xoltar,xzip,Itpl,logging} and would be
happy to share them (or, for that matter, describe them) if there's any
potential interest. I'd be happy to similarly package up any common python
modules
--- CUT HERE ---
#!/usr/bin/env python
import sys
import os
urpmflags = --media main-cooker,contrib-cooker
def readfile(fname):
return file(fname).readlines()
print Getting list of packages...,
pkgsfname = os.tmpnam()
os.system(urpmq %s --list %s % (urpmflags, pkgsfname))
pkgs = readfile(pkgsfname)
pkgcount = len(pkgs)
print pkgcount
obsoletes = []
provides = {}
print This may take a while...
pkgfname = os.tmpnam()
for i in range(pkgcount):
pkg = pkgs[i]
print \rprocessing #%4d/%4d: %s... % (i, pkgcount, pkg),
os.system(urpmf %s --provides --obsoletes %s %s % (urpmflags,
pkg.strip(), pkgfname))
provobs = readfile(pkgfname)
for line in provobs:
ptv = line.strip().split(':')
if len(ptv) == 3:
package, tag, virtual = ptv
if tag == 'obsoletes':
obsoletes.append([virtual, package])
elif tag == 'provides':
if not provides.has_key(virtual):
provides[virtual] = []
provides[virtual].append(package)
print \r,
for obsolete in obsoletes:
virtual, pkgo = obsolete
if provides.has_key(virtual):
for pkgp in provides[virtual]:
if pkgp != pkgo:
print %s obsoletes %s, provided by %s % (pkgo, virtual,
pkgp)
print And there you go
Re: [Cooker] That obsoletes thing...
On Friday 04 July 2003 10:37, Austin wrote: I will run it now. Austin I'm an idiot. I can do this all just by processing the synthesis files, with no calls to urpm*, can't I Never mind. I'll have a new script shortly. And I should be able to run it myself and report the results.
Re: [Cooker] Re: That obsoletes thing...
I've included the new-and-improved version, which runs in a couple of
seconds
On Friday 04 July 2003 10:54, Olav Vitters wrote:
You are looking for os.popen and friends.
OK, popen didn't work for my original version of the script, but for the
simplified version I posted it would have worked fine, yes, and I didn't even
think of it. Thanks.
Also, I have a few questions:
1. Is there a faster way to do this than running urpmf ~5000 times?
I already answered my own question--just read the synthesis file!
I've attached my version. Your version is still running, so I don't know
if it works correctly. Please compare it with the output of your version.
Don't forget to change the --media.
When I try this, it doesn't work. When I type urpmf --media
main-cooker,contrib-cooker --provides --obsoletes at a command line, I get
back a usage error from urpmf. I was hoping there was some way to tell urpmf
to operate on everything (or at least operate on this list of files), but
leaving the package name off doesn't seem to do it. (I've got 4.4-8mdk, if
that's relevant.)
4. Would anyone besides me want a python-URPM? (This would obviously take
some time, but I'd be happy to look into it.)
Might be nice.
OK, I'll look into it. Ideally it should provide the equivalent interface to
perl-URPM, right?
5. Is there actually no python-expect or python-pexpect? Would anyone
besides me want it? (This would take a few minutes.)
Searched for something like that last week. I found the following:
http://sourceforge.net/projects/pexpect/
Yeah, I meant is there actually no python-expect or python-pexpect package
for Mandrake, but I wasn't very clear. I've since found that drakian
provides a binary-only (alien'd) python-expect for python-2.1, but that's not
exactly what I want
Anyway, I have the latest versions of pexpect, python-expect, and ExpectPy;
making packages for them should be trivial. In my opinion, pexpect is the
coolest (it's pure python, and it's tiny, it's just about as efficient as the
others, and it handles the 95% most common uses for expect exactly like the
real thing), but it might be nice to have python-expect or ExpectPy as well
(since they actually wrap expect, they handle 100% of all uses exactly like
the real thing--and, if anyone cares, they work with python 2.1).
6. While I'm at it, does anyone want any other python packages? For my
own use, I've packaged up
python-{rational,cRat,fpconst,indices,xoltar,xzip,Itpl,logging} and would
be happy to share them (or, for that matter, describe them) if there's
any potential interest. I'd be happy to similarly package up any common
python modules
More Python packages are always welcome here.
OK, I'll submit them all.
--- CUT HERE ---
#!/usr/bin/env python
import sys
import os
import gzip
synthesispath = /var/lib/urpmi/
media = [ main-cooker, contrib-cooker ]
def readfile(fname):
return file(fname).readlines()
def zreadfile(fname):
return gzip.GzipFile(fname).readlines()
print Getting list of packages...,
everything = []
for medium in media:
everything += zreadfile(synthesispath + '/synthesis.hdlist.' + medium +
'.cz')
linecount = len(everything)
print linecount
obsoletes = []
provides = {}
print This may take a while...
tmpobsoletes = []
tmpprovides = []
for i in range(linecount):
line = everything[i].split('@')
if line[1] == 'provides':
tmpprovides = line[2:]
elif line[1] == 'obsoletes':
tmpobsoletes = line[2:]
elif line[1] == 'info':
package = line[2]
print \rline %6d/%6d: %s % (i, linecount, package),
for virtual in tmpprovides:
if not provides.has_key(virtual):
provides[virtual] = []
provides[virtual].append(package)
for virtual in tmpobsoletes:
obsoletes.append((virtual, package))
tmpprovides = []
tmpobsoletes = []
print \r,
for obsolete in obsoletes:
virtual, pkgo = obsolete
if provides.has_key(virtual):
for pkgp in provides[virtual]:
if pkgp != pkgo:
print %s obsoletes %s, provided by %s % (pkgo, virtual,
pkgp)
print And there you go
Re: [Cooker] Re: That obsoletes thing...
I've included the output from my synthesis files for the main and contrib cooker repositories as of late last night. It would probably be a good idea to sort on the virtual package name and/or actual package name, so, e.g., gimp and gimp1_3 would come out near each other Catching reciprocal problems might make it easier to read, and possibly ignoring kernel stuff (or -i stuff in general?). Anyway, looking at the list, assuming that: * everything related to the kernel is fine, * the MySQL vs. MySQL-Max conflicts are fine, * the glibc vs. uClibc conflicts are fine, and * most -devel conflicts are intentional (and fine), the only potential problems seem to be: * arts-1.1.2-2mdk vs. kde*-3.1.2-2mdk * apache-conf-2.0.46-2mdk vs. apache2-common-2.0.46-5mdk * php-cgi-4.3.2-6mdk vs. php-cli-4.3.2-6mdk vs. apache2-mod_php-2.0.46_4.3.2-3mdk vs. mod_php-4.3.2-1mdk * gimp-1.2.5-2mdk vs. gimp1_3-1.3.14-2mdk * libfnlib0-0.5-3mdk vs. libfnlib0-devel-0.5-3mdk * xine-lib-compat-plugins-0.9.13-11mdk vs. xine-plugins-1-0.beta12.5mdk * linuxdoc-tools-0.9.2-4mdk vs. docbook-utils-0.6.13-3mdk * openssh-askpass-3.6.1p2-4mdk vs. openssh-askpass-gnome-3.6.1p2-4mdk * yp-tools-2.8-1mdk vs. upserv-2.8-1mdk * gnome-tiles-1-6mdk vs. space-1.0.0-7mdk But here's the full output for masochists (or those who want to check it on their own system): --- CUT HERE --- glibc-2.3.2-4mdk.i586 obsoletes libc-static, provided by uClibc-static-devel-0.9.9-2mdk.i586 kernel-2.4.21.2mdk-1-1mdk.i586 obsoletes alsa, provided by kernel-enterprise-2.4.21.2mdk-1-1mdk.i586 kernel-2.4.21.2mdk-1-1mdk.i586 obsoletes alsa, provided by kernel-secure-2.4.21.2mdk-1-1mdk.i586 kernel-2.4.21.2mdk-1-1mdk.i586 obsoletes alsa, provided by kernel-smp-2.4.21.2mdk-1-1mdk.i586 kernel-2.4.21.2mdk-1-1mdk.i586 obsoletes alsa, provided by kernel-multimedia-2.4.21.0.18mdk-1-1mdk.i586 kernel-2.4.21.2mdk-1-1mdk.i586 obsoletes alsa, provided by kernel-multimedia-smp-2.4.21.0.18mdk-1-1mdk.i586 kernel-2.4.21.2mdk-1-1mdk.i586 obsoletes alsa, provided by kernel22-2.2.20-9mdk.i586 libalsa2-devel-0.9.2-5mdk.i586 obsoletes alsa-lib-devel, provided by libalsa-oss0-devel-0.9.0-0.5rc1mdk.i586arts-1.1.2-2mdk.i586 obsoletes kdeadmin3, provided by kdeadmin-3.1.2-2mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kdeartwork3, provided by kdeartwork-3.1.2-1mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kdebase3-nsplugins, provided by kdebase-nsplugins-3.1.2-24mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kdemultimedia3, provided by kdemultimedia-3.1.2-6mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kdepim3, provided by kdepim-3.1.2-5mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kdeutils3, provided by kdeutils-3.1.2-2mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kdegames3-devel, provided by kdegames-devel-3.1.2-9mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kdemultimedia3-devel, provided by kdemultimedia-devel-3.1.2-6mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kdepim3-devel, provided by kdepim-devel-3.1.2-5mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kdeutils3-devel, provided by kdeutils-devel-3.1.2-2mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kde3-xdrawchem, provided by xdrawchem-1.7.2-1mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kde3-scribus, provided by scribus-1.0-0.rc1.1mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kde3-ksplashml, provided by ksplashml-0.95.3-4mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kde3-ksetiwatch, provided by ksetiwatch-2.6.1-2mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kde3-kshowmail, provided by kshowmail-3.0.4-2mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kde3-keurocalc, provided by keurocalc-0.6.1-3mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kde3-knetfilter, provided by knetfilter-3.1.2-3mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kde3-komba2, provided by komba2-0.73-0.beta1.12mdk.i586 arts-1.1.2-2mdk.i586 obsoletes kde3-krusader, provided by krusader-1.20-3mdk.i586 apache-conf-2.0.46-2mdk.i586 obsoletes apache-common, provided by apache2-common-2.0.46-5mdk.i586 apache2-mod_php-2.0.46_4.3.2-3mdk.i586 obsoletes mod_php3, provided by mod_php-4.3.2-1mdk.i586 php-cgi-4.3.2-6mdk.i586 obsoletes php430, provided by apache2-mod_php-2.0.46_4.3.2-3mdk.i586 php-cgi-4.3.2-6mdk.i586 obsoletes php430, provided by php-cli-4.3.2-6mdk.i586 php-cgi-4.3.2-6mdk.i586 obsoletes php, provided by apache2-mod_php-2.0.46_4.3.2-3mdk.i586 php-cgi-4.3.2-6mdk.i586 obsoletes php, provided by php-cli-4.3.2-6mdk.i586 php-cgi-4.3.2-6mdk.i586 obsoletes php, provided by mod_php-4.3.2-1mdk.i586 php-cli-4.3.2-6mdk.i586 obsoletes php430, provided by apache2-mod_php-2.0.46_4.3.2-3mdk.i586 php-cli-4.3.2-6mdk.i586 obsoletes php430, provided by php-cgi-4.3.2-6mdk.i586 php-cli-4.3.2-6mdk.i586 obsoletes php, provided by apache2-mod_php-2.0.46_4.3.2-3mdk.i586 php-cli-4.3.2-6mdk.i586 obsoletes php, provided by php-cgi-4.3.2-6mdk.i586 php-cli-4.3.2-6mdk.i586 obsoletes php, provided by mod_php-4.3.2-1mdk.i586 mod_php-4.3.2-1mdk.i586 obsoletes mod_php3, provided by apache2-mod_php-2.0.46_4.3.2-3mdk.i586 mod_php-4.3.2-1mdk.i586 obsoletes php3, provided by
[Cooker] Contrib packages: Lots of python modules
In brief, I've uploaded python modules for: expect emulation (pexpect), rational numbers (cRat), IEEE floating point constants (fpconst), string i = $i interpolation (Itpl), logging (logging), and functional programming (xoltar). Now, the full package descriptions: python-pexpect-0.98-1mdk: This is a pure-python replacement for Expect, a module that allows easy control of other applications (including interactive applications that would drive popen crazy). It's not 100% compatible with the real thing, but its at least 90% compatible, and much easier to use. python-cRat-0.7-1mdk: This is an efficient Python module for rational numbers. In particular, it uses an improved gcd algorithm (encoded in C), which dramatically increases speeds for large rationals. python-fpconst-0.6.0-1mdk: This module provides constants and functions for handling IEEE754 floating point infinite and NaN values. This works on any python that uses IEEE754 double values for its float type (whether big- or little-endian). Although this is not required, it's unlikely any python would fail to meet this requirement (the code in both the standard and JPython interpreters assumes IEEE754 double all over the place). python-Itpl-0-1mdk: This is a python module for interpolating strings (that is, for expanding variables within strings), as described in PEP 215. This module may become part of the standard library, or the functionality may be built into Python in the future. python-logging-0.4.7-1mdk: This is a python module that implements a full-featured logging system in line with PEP 282 (comparable to java.util.logging, log4j, etc.). python-xoltar-0.20010601-1mdk The Xoltar Toolkit is a collection of useful utilities for programming in Python. Aside from the threadpool module, the toolkit is mostly concerned with enabling a functional programming style in Python. Here's some other packages I have, which I didn't upload, as they seem less likely to be of general interest. If anyone wants any of the following, let me know and I'll lint it and upload it: * ExpectPy: The best expect wrapper. If you need 100% expect compatibility, you might want this. Otherwise, use pexpect. * expect: The classic expect wrapper. If you know and love tcl, you might want this. Also, many other linuxes include this module, so you might want it for compatibility reasons. Otherwise, use pexpect or ExpectPy. * rational: Another rational numbers module, not as efficient as cRat, but closer to the proposed spec, and extending it with correct inf/NaN handling. If you really need the right answer for float(rational(0)/rational(0)) * decimal: Arbitrary-precision, precision-preserving decimal fractions (1.1 + 1.274 = 2.4). * Decimal: Arbitrary-precision, precision-extending decimal fractions (1.1 + 1.274 = 2.384). * fixedpoint: Arbitrary-precision, fixed-precision decimal fractions (1.1 + 1.274 = 2.4; 1.274 + 1.1 = 2.384). * FixedPoint: A different implementation of the same idea. * indices: A module that provides various ways to enumerate an iterator--both enumerate (which will be in python 2.3) and indices, xindices, irange, and xirange (rejected for 2.3 in favor of enumerate). For example, instead of for i, e in zip(range(len(seq)), seq) use for i, e in irange(seq). * accumulate: Everyone's favorite higher-order function missing from python. * xzip: A module providing xzip, xmap, and xfilter (all rejected for 2.3). * ClassMixer: Automatic generation of mixin classes. * gensim: Generator comprehensions and parameters, ala PEP 279 (rejected), more of a proof-of-concept than truly useful. * normalDate: A simple date library. * pyFinancials: Financial calculaton toolkit. * Pool: A simple allocator library. * pimap: An IMAP library, together with a console client, both incomplete. * IPP: Enhanced interactive python prompt. * n8gray-stuff: All of n8gray's tools, which are mostly geared toward improving the interactive prompt. * ihelp: Access help (man pages, info, etc.) from the interactive prompt. * pyrepl: Readline on steroids.
Re: [Cooker] Re: That obsoletes thing...
On Friday 04 July 2003 12:28, Olav Vitters wrote: On Fri, Jul 04, 2003 at 11:24:51AM -0700, Andi Payn wrote: Using urpmf would avoid possible breakage due to a synthesis file format change. True. But once I write python-URPM they'll both be obsolete anyway. And this tool isn't meant to be permanent; if it is, it should go into the whole suite of urpm checking stuff. The speed seems to be comparable. If I had gotten yours to work, I might not have bothered writing my new version. Use : urpmf --media main-cooker,contrib-cooker --provides --obsoletes Thank you! Now, is there any way to get it to handle a specific list of packages, short of -o .join(packages)? OK, I'll look into it. Ideally it should provide the equivalent interface to perl-URPM, right? I think so. It would make it easier to switch from PerlPython. This should convince Mandrake to dump Perl and go with Python. ;) Impossible. To a perl-head, the more ways there are to do something, the better. So, they ought to welcome a python module with open arms, but that doesn't mean they'll want to give up the perl module. If anything, it'll just cause them to ask where the tcl and lua and scheme modules are Pretty soon I'm going to play with Expect again. I've written lots of Tcl/Expect and while Tcl is fun, I sometimes wanted good and fast datastructures (like Python has). Some of the Python expect wrappers just help to generate tcl strings (with a little help) and call the interpreter on them. ExpectPy wraps the tcl stuff in python layers (and since the actual interaction is often not the slow part, that's sometimes perfectly fine). But pexpect is pure python, top to bottom. Unless you need 100% compatibility, that's what you want. Plus, that's the one I uploaded, and it'll be easier for you to bend to my will than to download another package and build it yourself The version I posted has the last line wrong (extra indent). Sometimes emailing python scripts can be annoying when you're not using a text-mode mail client. But I love the python whitespace rules anyway (after getting past the initial ohmigod-what-is-this-FORtran-or-something?!? reaction, just like every other Python convert I've ever met or heard of). And it's still not as annoying as when Eudora used to sometimes confuse perl scripts with some pre-MIME Mac binary encoding format (which was the version of binhex one later than the one everyone used?). Or [EMAIL PROTECTED]
[Cooker] Contrib package: rfc-3.2-1mdk
From the package description: This package contains a script for reading RFCs off the Internet from the shell (by starting your favorite browser, or just dumping it to stdout). It also includes an emacs list package to read RFCs from emacs. It's not perfect, but it's much better than ftp-rfc.
[Cooker] Contrib packages: python-perlmodule-1.0.1-1mdk and perl-Inline-Python-0.20-1mdk
One package lets you call perl code from with python; the other lets you call python code from within perl. Whichever one you use, the embedded language can call back out to the host language. There are some differences (python-perlmodule generally imports perl modules, while perl-Inline-Python compiles and executes arbitrary python code inline with the perl), but they're both quite nifty. By the way, the original name of python-perlmodule is pyperl, but the whole name thing is a bit confused because it's from CPAN rather than Starship From the package descriptions: python-perlmodule: Perlmodule makes it possible to embed perl interpreters in any python program. It can be used to invoke arbitrary perl code, load any perl modules, and make calls directly into perl functions. The perl code invoked can call back into python as it sees fit. This package is built with MULTI_PERL enabled--each python thread gets its own separate perl interpreter. perl-Inline-Python: The Inline-Python module allows you to put source code from Python directly inline in a Perl script or module. The code is automatically compiled as needed, and then loaded for immediate access from Perl. The Python code will be able to call back to the Perl code at will. However, if you want the ultimate host language to be Python, use python-perlmodule instead. Inline-Python relies on the Inline module to do most of its work; many other languages can be inlined besides Python.
[Cooker] Contrib package: libsigc++1.0-1.0.4-6mdk
The current versions of libsigc++1.0 and libsigc++1.2 can't coexist. This means that you can't have both 1.x and 2.x versions of gtk--, gnome--, and glade--. But there's no good reason that they shouldn't be able to; it's just an artifact of the packaging. And there are plenty of good reasons to want both around. With a few minor changes to the 1.0 version, I was able to make them coexist. The only negative is that the libsigc++1.0 no longer provides the virtual package name libsigc++ (and similarly for the -devel package). Since (in 9.1, and in current Cooker) 1.0 is in main and 1.2 is in contribs, possibly this should have been done the other way around (let 1.0 provide libsigc++ and instead change 1.2). But the difference should only be visible to users who (a) develop with Gtk-- 1.x but not 2.x, and (b) use non-Mandrake packages that depend on libsigc++, I doubt anyone will complain. Fortunately, the relevant gtkmm, gnomemm, and glademm packages already know how to coexist, so this is the only change needed to develop Glade-- code for 1.2 and 2.0 on the same box. By the way, my first attempted upload failed, so please look at file libsigc++1.0-1.0.4-6mdk.src.rpm.2 for the correct package.
[Cooker] Contrib package: hot-applet-0.2.2-1mdk
Updating my earlier hot-applet package to the new version. Everyone (who uses this) should upgrade. According to the author, 0.2.1 had a minor bug that could cause it to crash on every computer; 0.2.2 does not. Dell laptop users should continue to use hot-applet-for-dell-0.2-1mdk instead. While I was at it, I updated the specfile a bit (e.g., hot-applet now conflicts with hot-applet-for-dell). From the package description: This GNOME panel applet shows motherboard sensors values, such as CPU Temperature, fan rpm's, etc. Note: I have tested that the new version runs, but since one of my boxes doesn't support lm_sensors, and the other uses funky values none of which hot-applet knows about, all I can say for sure is that it doesn't crash either machine
[Cooker] Contrib changes to lua*.rpm
I've uploaded two specfiles: lua4.spec and lua.spec. The first replaces lua.spec from lua-4.0.1-1mdk.src.rpm. The second replaces lua.spec from lua-5.0-1mdk.src.rpm. (I've also uploaded the resulting SRPMs, especially since the 4.0 version doesn't appear to be available on cooker anymore.) Both have only minor changes, the goal of which is to allow lua4 and lua5 to coexist: lua.spec was renamed to lua4.spec (and the SRPM to lua4), and the executables are now controlled by update-alternatives. Since there are existing packages embedding both versions, and it's not always trivial to update a package to embed the new version, the shared libraries need to be able to coexist. In the current packages, the interpreter and compiler (/usr/bin/lua and /usr/bin/luac, and their man pages) are in the library RPMs, which prevents them from doing so. One solution would be to move the executables into a new package (lua-*.rpm, or into the -devel package (liblua*-devel*.rpm). I haven't tested whether the shared libraries can be embedding if the interpreter executable is missing, but I'd assume they can. Alternatively (NPI), update-alternatives can allow both versions of the interpreter and compiler to coexist. This has the added advantage that a developer who's trying to update her scripts (or her embedding app) from lua4 to lua5 can do so much more easily. This also involves a slightly smaller change to the specfile than the other solution. So, I chose to do it this way. Neither package can coexist with the older packages (4.0.1-1mdk and 5.0-1mdk), so I put in explicit Conflicts tags. A few minor issues: The manpages are not controlled by update-alternatives (the old versions are simply called lua4 and luac4). Although it seems to make sense that man lua should call up the lua4 manpage if lua4 is your currently-selected alternative, it looks like other packages don't do this, so I didn't. It might be useful to split the interpreter and compiler off into a separate package from the shared libraries even though update-alternatives makes this unnecessary. On the other hand, I assume that whatever reason Lenny had for including them in the lib package two years ago (when he libpolicy-ified lua-4.0) still makes sense. If you rpm -ivh both SRPMs to ~/RPM, then try to build them both, it may not work (they have a patch file with the same name). I haven't tested that. If you rpm -ivh one, build it, rpm -ivh the other, and build it, that works (in either order); rpm --rebuild on the SRPMs also works fine.
[Cooker] Contrib package: openclit-12-1mdk
From the package description: OpenCLit converts ebooks from the proprietary Microsoft .lit format to the Open eBook format. There are no programs that can read .lit books for linux (or anything but recent versions of Windows and PocketPC), so this is the only way to read .lit files. Unfortunately, the only programs that can handle Open eBook files on linux are closed source (e.g., Opera), but the .opf file is an XML document, and the actual text and graphics are stored in standard formats like html and jpg. The DRM5 features do not work on linux (you need a registered copy of Microsoft Reader, and there is no such thing for linux), but the main functionality (converting to Open eBook format) works just fine. The name and version number are pretty inconsistent (it's openclit, clit, clit12, convertlit, etc., and the version is 12 or 1.2), but I think this is that openclit-12 is the best way to name the package (and the binary is /usr/bin/clit). A few possible issues: * The code is distributed as GPL according to the website, but there's no COPYING or LICENSE file--so, while the copyleft notice is included in the source, it won't make it anywhere into the binary package. * One of the included libraries (which it statically links) is GPL'd by another author (the rest are public domain), and his copyleft message won't appear anywhere in the binary package either. * Converting .lit books that you own into a format that you can read on linux (or a Palm, or even an older PocketPC or Windows box) should be legal fair use in America or any Berne Convention signatory (just like programs to convert .doc, .pdf, etc. to other formats), but I am not a lawyer, and neither is the author. * The source contains code for DRM5 stuff, some of which might make Microsoft unhappy (and some of which might be more useful for pirates than for legitimate users). However, none of this code gets built under linux. * There are some offensive puns throughout the source code (you can guess them from the package name). If any of these issues prevent Mandrake from wanting to distribute openclit, hopefully the PLF people will want it. (You can get a copy from the same place as the other packages I submitted to PLF earlier.)
[Cooker] Contrib package: zero-inst
From the package description: The Zero Install System is a URI-based network filesystem, together with a mechanism for running applications (including any necessary libraries) directly off the internet. Instead of installing an application, a zero-inst user can just start the application by its URI. Any needed binaries are downloaded and cached locally, so there's essentially no speed hit. For frequently-used applications, a user can add a menu entry, web link, bash alias, etc. that points to the URI. Note that zero-inst is still a work in progress. Since it requires a kernel patch, and the whole point is to run binaries directly from the internet, it's probably a bad idea to use zero-inst on a production system at this stage. See http://zero-install.souceforge.net for more details. The zero-inst developers are all Rox users, so the documentation is a bit focused on Rox users, but it works just fine with any KDE, GNOME, or no desktop at all. However, at present, there are only a few demo programs available for zero-inst (all in /uri/http/zero-install.sourceforge.net/demo, and all built only for ix86), so it's not terribly useful yet. The source package builds two binary packages: zero-inst and zero-inst-kernelmod. You need to have the kernel source for the kernel you want to run against to build the package, and you need to be using the matching kernel version to install the -kernelmod package. I couldn't think of a good way to check this. I put in a BuildRequires: kernel-source but that doesn't really cover it. (What if you're using kernel-multimedia? Or if you've upgraded to a new kernel but still have the old kernel-source?) And there doesn't seem to be any way to make the binary package require the kernel version used for building (another feature for automated requirements gathering?). The kernel module handles the virtual filesystem; updating the cache is done with user-space tools. The tool to automatically download files the first time (zero-install) is pretty much complete, but the tools for throwing away old cached files when they're unneeded (or for updating to newer versions) aren't. Also, while zero-install is downloading files, the parent process locks up with no feedback, and the tools to see what's happening are only partially complete (try the 0show command-line tool). I slapped together an init script, RPM pre/post scripts, etc. in about a half hour, and they may need more work--it seems to work fine for me; that's all I can promise.
Re: [Cooker] Document review request: RPM devel package dependency problem
On Sunday 06 April 2003 13:26, Stefan van der Eijk wrote: Hello, I've written up on an issue with rpm dependencies in -devel packages. I'm not sure if the story is 100% accurate (I'm not a programmer), so if you've got a moment to spare, feel free to review it. This is pretty much completely wrong. The history is wrong, the description of the problem is wrong, and the proposed solution won't work. The proposed solution might have some benefits anyway; I'll get to that. Rather than explain what's wrong, let me try to give a more accurate history, with some rationales along the way, and then explain the actual problem, and why it can't be solved automatically. This is probably going to be a very long email, as there's a lot to go over. In the old days, Mandrake worked the same way Redhat did (and, along with most of the RPM-based world, still does): The typical source package mything-1.0.srpm, if it contained libraries or other development files, would build two packages, mything-1.0-i586.rpm and mything-devel-1.0-i586.rpm. The mything package would contain the application binaries, shared libraries (libmything.so.1.0.0), shared library symlinks needed for normal use (libmything.so.1), and user documentation. The mything-devel package would contain the static libraries (libmything.a), shared library symlinks needed for building other code (libmything.so), header files, and developer documentation. This split long predates the Mandrake policy; it came long before the numbering of libraries. Also, this split has no effect whatsoever on the ability of multiple versions to coexist. For example, mything-1.0 can't coexist with mything-1.2, because they both try to provide the same files, such as /usr/bin/myapp. Likewise, mything-devel-1.0 can't coexist with mything-devel-1.2, because they both try to provide the same files, such as /usr/include/mylib.h. Naming them differently wouldn't solve this problem; it would just make it harder for RPM to catch the problem immediately (it has to go through the preparing phase--which, for urpmi/rpmdrake, means it has to download the packages). The reason for splitting off the -devel packages was that most people don't need them. Why waste download time, space on the CD, space on the user's hard disk, and/or other resources for header files if most users will never compile anything that requires those header files? In a few cases, packages were further split: -static-devel, -doc, -devel-doc, -utils, -tools, etc. may be split off. This was pretty rare in the early days, and on most distros (including Mandrake and Redhat), it's still pretty rare, but a few distros went overboard with this (PLD' policy is to create separate -static, -static-devel, and, where appropriate, -docs and -docs-devel, for example, and Conectiva goes about half-way there). Sometimes this is because the static libraries end up being 80% of -devel and even most developers will never need them--so again, it saves space/bandwidth/etc. to separate them out. Sometimes it's because the original program came in multiple separate tarballs and it's easier (both initially and for maintenance) to organize the RPMs the same way. Sometimes it's because the developer puts a specfile in each tarball, which makes this even more compelling (especially when the specfile is designed for your distro). Often it's because whoever had the package first split off -static-devel and everyone else just followed suit (this is especially true when developers make Mandrake packages and Redhat redhatizes them). Now, on to the multiple-version issue. This was a problem from the beginning of the shared library days, before RPM. Let's say that lots and lots of packages link to mything's shared libraries. Now, 1.0 comes out, and it's incompatible with 0.2. Let's look at the library version numbering system used by linux/glibc. When a user upgrades from mything-0.2.1 to mything-0.3.0, /usr/lib/libmything.so.0.2.1 goes away, /usr/lib/libmything-0.3.0 gets installed, and the existing /usr/lib/libmything.so.0 link now points to the new version. Since programs link against libmything.so.0, all existing programs still work, and programs that require new 0.3 features also work. (This assumes that minor-version upgrades are backwards compatible, which they're supposed to be, but some developers disagree, or just aren't perfect.) When the user later upgrades to mything-1.0.0, which may be incompatible with 0.3.0 (major-version upgrades can be incompatible), libmything.so.0.3.0 stays in place, and libmything.so.0 continues to point at it, while libmything.so.1.0.0 is added, and libmything.so.1 points at the new version. Old programs still work because they still have the old library; new programs work because they have the new library. Other operating systems with shared libraries have similar problems, and handle them in similar ways (except classic MacOS and a few other OS's
Re: [Cooker] Re: kernel-multimedia-2.4.21.0.18mdk-1-1mdk
On Sunday 06 April 2003 18:05, Brian J. Murrell wrote: I agree that it should be the stock kernel + multimedia needs (ONLY!). I don't want it to be a hackkernel either. Maybe there should be a kernel-hack in contrib. There are probably people who are using (or would use, if they knew about it) -mm who aren't doing any multimedia, just because they want some of these patches (like supermount). That's fine, but those people shouldn't be arguing for patches to go into the next version of -mm. And if they had a separate -hack kernel where they could get the patches they wanted, they wouldn't be. If, as Austin Acton suggests, you broaden the definition of multimedia to mean something like pure desktop computing, that still leaves out plenty of patches that have nowhere else to go, and the broader definition will only make people more likely to try to get them crammed into -mm. The obvious question is, who is the hack kernel for? Nobody's going to want to turn on every patch in the world, right? Well, I know quite a few people who configure and rebuild kernels all the time but never patch them. (With FreeBSD, even beginners are expected to configure and rebuild their kernel, but only experts are supposed to patch it)
Re: [Cooker] [Gnome] your favourite applet?
OK, this will take a bit longer than expected (see my next message for why), but I should have all of the following (assuming none of them turns out to not work with 2.2) within the next day: quick-lounge-applet file-menu-applet sensors-applet hot-applet netspeed-applet divider-applet Note that I tweaked some of the names a bit to make them all consistent (in particular, all are suffixed with -applet, and none are prefixed with gnome-). You may need to upgrade some gnome packages to build and/or install these; I'll have the details when the packages are done. On Friday 04 April 2003 14:07, MEISCH,CORY (HP-Vancouver,ex1) wrote: I would be interested in goats... So would I, but nobody's gotten it to work for Gnome 2.2 yet, as far as I know. The same is true of the other sticky-notes panel that I know about. In fact, trying to port gnome-sticky-notes from 1.2 to 1.4 was a huge nightmare, so I suspect porting goats from 2.0 to 2.2 may not be trivial either. But maybe it will be; I'll take a look.
[Cooker] More minor problems in the Gnome/Gtk packages
First, libgnome-vfs2_0-devel provides pkg-config support, but not gnome-config support. Since it seems like most of the panel applets use gnome-config to test for requirements during configure, this is a problem. I slapped together a /usr/lib/vfsConf.sh that just forwards the pkg-config info, and I'll have a new package (libgnome-vfs2_0-devel-2.2.2-2mdk) ready in an hour or so. You'll need this new package to build some of the panel applets I'm packaging (but not to install binaries). Second, the naming, version numbering, and virtual packages are really inconsistent between the various Gtk+/Gnome packages, which makes it really annoying to port Redhat packages. For example, looking only at the packages that quick-lounge-applet requires: * libgtk+2.0_0-devel provides no virtual names * libglib2.0_0-devel provides glib2-devel, libglib2-devel, libglib2.0-devel * libglade2.0_0-devel provides libglade2.0-devel * libgnome2_0-devel provides libgnome2-devel * libgnome-vfs2_0-devel provides gnome-vfs2-devel, libgnome-vfs2-devel * libgnome-desktop-2_2-devel provides gnome-desktop-devel, libgnome-desktop-2-devel * libpanel-applet-2_0-devel provides libpanel-applet-devel, libpanel-applet-2-devel, gnome-panel-devel So, some of the packages are named libnameMAJOR_MINOR-devel, while some are libname-MAJOR_MINOR-devel. Some provide libnameMAJOR-devel as well, some don't. Some also provide libname-devel, name-devel, and/or nameMAJOR-devel. (There are similar issues with the libnameMAJOR_MINOR non-devel packages, of course.) In other words, I can't count on listing libnameMAJOR-devel as a requirement; instead, I have to do an rpm -q --provides on each one to see what I can list. It would be really nice if someone would go through and fix all of this--get rid of the extra trailing hyphens in some of the packages, provide all four useful virtual packages (plus whatever others are appropriate, like gnome-panel-devel, and whatever's needed for backwards compatibility with the existing packages, like libpanel-applet-2-devel and libpanel-applet-2_0-devel).
[Cooker] New contrib packages: a bunch of GNOME panel applets
I've uploaded 6 packages, each containing a GNOME panel applet. All of them came with a specfile for a Redhat package; they had to be heavily tweaked to work in Mandrake (or at all--two of them didn't have a %files section, so they couldn't possibly work anywhere, could they?), but I tried to leave the descriptions, etc. alone except where the English was excruciatingly bad (This applet show your CPU hot) Ignore the earlier post about needing to change some of the GNOME packages; I believe everything should work with 9.1 as-is. * quick-lounge-applet-1.1.3-1mdk Organize your preferred applications on the GNOME Panel. It's a quick-launch toolbar modeled after the one in Windows (it even has a menu at the right for any entries that didn't fit). Goes in the Utility category (on the Add to Panel menu). After minimal testing, it seems to work. For some reason, the package builds as an so applet rather than an exe applet, but the panel doesn't care; it's only confusing to people who go manually digging through their /usr/lib directory. * gsensors-applet-0.9a-1mdk (aka GNOME-sensors) Monitor hardware sensors on the GNOME Panel. A graphical representation of lm_sensors data. Goes in the Utility category. Has no icon. If you don't have sensors enabled (that is, you haven't at least done a modprobe i2c-proc), it unceremoniously crashes. When I enable sensors, it seems to only want to display my last sensor, which happens to be one that's not recognized by lm_sensors, and therefore useless. (This is on a Dell PowerEdge with a billion or so sensors, most of which linux doesn't recognize.) Someone else might have better luck. * hot-applet-0.2.1-1mdk (aka hotapplet) This GNOME panel applet shows motherboard sensor values, such as CPU Temperature, fan rpm's, etc. Another lm_sensors GUI. Shows up as System Temperature Monitor in the Utility category. If you don't have sensors enabled, it tells you nicely why you're not seeing anything. If you do have sensors enabled, but it's confused by your sensors (as with mine--see above), it crashes. I don't know what it does if you have a more common setup; again, someone else might have better luck. * hot-applet-for-dell-0.2-1mdk (aka hotapplet-for-dell) This GNOME panel applet shows motherboard sensor values, such as CPU Temperature, fan rpm's, etc. The same GUI, but around Dell laptop sensors rather than lm_sensors (although it still requires lm_sensors to build, which it shouldn't). Shows up as System Temperature Monitor in the Utility category. Conflicts with regular hot-applet. I don't have a Dell laptop to test on, but I get a nice message telling me that I don't have Dell laptop support compiled into my kernel; no crashes. Someone else will have to test this. * netspeed-applet-0.8-1mdk (aka net_speed_applet and netspeed_applet) A little GNOME applet that shows the traffic on a specified network device (for example eth0) in kbytes/s. Goes in the Internet category. It seems to work well, and is pretty configurable. If I didn't use gkrellm, and if it could display speed on another host's devices, I might use this all the time. The installer does all kinds of scrollkeeper-related work (builds new indexes, etc.) which I just throw away. It might save a few seconds to skip this. * divider-applet-1.99.1-1mdk (aka divider_applet) A GNOME panel applet that adds dividers to the panel similar to toolbar dividers. It provides a bunch of different divider styles, each of which can be thickened or colored to your heart's content. Goes in the Amusements category, which is probably not appropriate. This seems to have some visual glitches. When adding a new divider or changing the divider style, I often have to either wiggle the strength setting or restart the panel to get it to show up properly. This may not happen for those using approved themes (Geramik or Galaxy); someone should check. Also, some of the divider styles do not look right on a small horizontal pattern; they all look fine on medium or larger, or any horizontal. I did not package the following applets that were requested: * goats: Won't build for 2.2; at least it's not trivial to do so. * sticky-notes-applet: Ditto. * file-menu-applet: Sorry, it's a 1.x applet only (it came with GNOME 1.2).
[Cooker] New contrib package: sticky-notes-applet
I know everyone misses Goats from GNOME 2.0, and Sticky Notes from GNOME 1.x before it. Well, there's a new applet, again called Sticky Notes, that works fine in GNOME 2.2. In fact, it's part of the gnome-applets CVS module (at least since 20 Feb 2003, maybe longer), but it's not in Mandrake's package. So I created a separate package for it: sticky-notes-applet-1.0.11-1mdk.src.rpm. The applet shows up in the Accessories category. And everything seems to work without a hitch. When Mandrake goes to a newer version of gnome-applets that includes this applet, please remember to obsolete this package!
[Cooker] Making ncftp bookmarks from your urpmi sources
I don't know if this is useful to anyone else besides me, but just in case:
Sometimes, when files are updated on a mirror but the hdlist isn't (or you're
in the middle of a long download, or whatever), you can't get them through
urpmi. But, if you're using ftp sources, you can just ncftp to the site and
get the newer versions manually.
In rpmdrake, you can see which source the package comes from (for example,
main-cooker, or whatever you called it when using urpmi.update or
urpmi.setup). But you probably don't know the URL for main-cooker off the top
of your head, and wouldn't want to type it even if you did.
That's where ncftp bookmarks come in. You can create an ncftp bookmark for
each of your sources, and just type ncftp main-cooker to go right to it. I
did this manually, but each time a new version comes out, or your favorite
mirror rearranges their paths (e.g., moving 9.0 from mandrake to
mandrake-old), you have to update it in two places (urpmi and ncftp). And I
have a ton of sources.
So I wrote a script to automate this.
Cut and paste the end of this message as urpmi2ncftp, then do this:
chmod +x urpmi2ncftp
./urpmi2ncftp ~/.ncftp/bookmarks
Then you can type ncftp main-cooker (assuming you have a urpmi source called
main-cooker) and you're there.
Of course this only works with ftp sources. If you're using rsync or http or
even ftp with authentication, you're SOL. (My local copy of the script knows
how to convert mirrors.secsup.org's rsync URLs to the appropriate ftp paths,
but there's no general way to do that)
So, here's the script:
--- CUT HERE ---
#!/usr/bin/perl
use strict;
use urpm;
use URI;
use Socket;
my $urpm = new urpm;
$urpm-read_config();
foreach my $media (@{$urpm-{media}}) {
my $uri = URI-new($media-{url});
if ($uri-scheme eq ftp) {
print($media-{name} . , .
$uri-host . .
$uri-path . , .
I, .
$uri-port . ,4294967295,1,1,-1,1, .
inet_ntoa(scalar gethostbyname($uri-host)) .
,,S,-1,\n);
}
}
[Cooker] TEG problems
The game TEG (Tenes Empanadas Graciela, the clone of a Risk clone) no longer works on any of my systems. During the attack phase, as soon as you click on a source country, the client crashes. An earlier version worked on a nearly-clean 9.0 system, and an early post-9.0 cooker system with all kinds of stuff installed. The current version (0.11.0-1mdk) doesn't work on a nearly-clean 9.1 system, or a current cooker system with all kinds of stuff installed, or on a perfectly clean 9.1rc1 system (that's the latest version I had CD's handy for). I don't know if the problem is in teg or something else that's changed. Is anyone else having this problem? (For that matter, is anyone playing the game successfully?)
Re: [Cooker] Mozilla roadmap and Cooker
On Saturday 05 April 2003 15:29, J.A. Magallon wrote: it looks like Mozilla application is dead. Now we will have a Mozilla-suite, split in several apps: No no no, the whole point is to get _away from_ the Mozilla-suite idea, not to move toward it! There will still be something that you can download as an application suite if you want, but it'll be a collection of separate, decoupled applications and extensions that can just as easily be used independently. - Mozilla browser is dead. They will switch to Phoenix (or whatever is it named after the copyrights war the seem to be inside...) The existing default Mozilla browser (Seamonkey, aka /usr/bin/mozilla) is not dead. At the end of November, when the stable 1.6 release is due, it will be dead; until then, it's not. Phoenix, meanwhile, is still not done. You can, of course, just download Phoenix right now and use it alongside/instead of Mozilla. But you're probably better off using Galeon or Konqueror. - Mozilla mailer is dead. Use Minotaur. A beta build is available. Minotaur is not ready yet. Use Mozilla mailer. A beta Minotaur build is nowhere near ready. An experimental build of Minotaur is available. To quote the download page, Please not that Minotaur is currently not even alpha quality software. Meanwhile, the existing mailer is getting upgrades for 1.4, and possibly for 1.5. You may want to play with Minotaur (to help development, or just to get an idea of what changes are in store for the future), but you definitely don't want to use it as your mail agent. You're probably better off with Kmail or Evolution or any of the thousand other mail agents out there. - All they will build against GRE. Mozilla, Phoenix, Minotaur, and many other apps already build against Gecko. - And java now is gcc-3 safe... Which is relevant how? Do you see feasible to (;)): - include GRE in cooker Meaning the Gecko engine? It's already in cooker--and 9.1 and 9.0--as part of the mozilla package. If you mean splitting mozilla into, e.g., mozilla, libgecko, and libgecko-devel, that's not a bad idea, but it's a lot of work--work that will have to be redone for 1.4 and 1.5 and possibly the minor upgrades along the way before being thrown out for 1.6. It's probably not worth it. If you instead mean that some to-be-determined future version of Gecko with its interfaces refactored in some to-be-determined future way should be included in cooker--well, it's pretty hard to include something that doesn't exist. - build phoenix against it (gcc3) What else could you build Phoenix against besides Gecko? If you want a Phoenix package for Mandrake, there are a lot of issues to consider. Phoenix hasn't been designed for system-wide installation; it works much better if you just unpack the tarball into your home directory and run it from there. Since Phoenix relies so much on letting users updating its chrome directory (to install extensions or themes, for example), a shared installation pretty much means that only root can configure it. Hopefully some future version will pop up a su wrapper to let anyone install a new extension, separate out installing the extension from enabling it, etc. Anyone who can't handle installing Phoenix without an RPM probably won't get much use out of it yet. - build galeon against it (and so, nautilus...) Again, what would Galeon be built against besides Gecko? Why do you think the galeon package requires the mozilla package? - include some other projects as epiphany ;) Epiphany is yet another Gtk-native browser wrapped around Gecko, like Galeon and Skipstone, but with tighter GNOME integration (it's sort of the exact opposite of the everything-is-cross-platform Phoenix). It's nowhere near complete, and I suspect that anyone who can't install it from source won't have much reason to play with it yet. I know it is a very very big deal, but you could take it as your 'web-browsing-in-mandrake roadmap'... Considering that Mandrake's default desktop is KDE and their default browser is Konqueror, I suspect that they won't go for any roadmap that focuses on Galeon and Epiphany Obviously, Mandrake will have to take the future of Mozilla into account, but they can do that just by tracking future versions of Mozilla, Galeon, and other projects, just as they've done all along.
[Cooker] Problems with ftp.linux-mandrake.com?
I've been trying to upload a few packages for hours now, and the server just times out. I even went and checked the Cooker development page to make sure I was using the right URL (ftp://ftp.linux-mandrake.com/incoming/). The address resolves to 63.209.80.249, on a few different nameservers, so I assume the problem is with the FTP server itself--either it's down, or it's been incredibly busy. I've already sent out the emails for these packages; when I get back later today, I'll try the uploads again.
Re: [Cooker] [Gnome] your favourite applet?
On Friday 04 April 2003 03:11, Helge Hielscher wrote: My favourites are the file menu applet and the quick-lounge-applet (the only way to have small Icons on a vertical panel; not yet listed in above url, http://quick-lounge.sourceforge.net/). Actually, all of my favorites are already included (Weather Report, Show Desktop, Clock, System Monitor, Volume Control, Workspace Switcher, Keyboard Layout Switcher, and Fish), and I don't have any need for either of these. But, if people want them, and nobody else is going to do it, I can have packages for file-menu 0.5 (assuming it's 2.2-friendly; it doesn't say anywhere) and quick-lounge 1.1.3 (this one says it is 2.2-friendly) by tomorrow. Any more applets you want? A couple I've been curious about: * G2AS. I've heard that people have made it work with 2.2, but I've failed. * Goats or StickyNotes. Has either been ported to 2.2? Are there others? * GTransferManager. The app works, but the applet seems to have disappeared? * Gnome Sidebar. Is this in a working state yet? * QuickRecord. Has this been ported to 2.2? * XMMS Applet (the one built w/Entity for 1.x), or anything similarly compact.
[Cooker] Speaking of .net stuff...
I've been playing around with pnet, and there's a little problem. Both pnet and wine can handle MZ (Microsoft's extended version of their PE format, which handles both native Windows binaries and ICS/.net portable apps), but you can't register two handlers for the same binfmt. Fortunately, pnet's interpreter forwards to wine if it finds a Windows native file, so you want to register that as the handler if you're using both wine and pnet. But of course you want to register wine as the handler if you're not using pnet. I've modified the wine initscript to work friendlily with the pnet initscript, so you can use both. I'll be happy to put together updated wine and pnet packages if people want (once I can get into the server), but for now, here's how to do it yourself in three semi-easy steps. 1. Copy the pnet script supplied in the package: cp /usr/share/doc/pnet-0.5.2/init.d-pnet /etc/rc.d/init.d/pnet 2. Modify the wine script as follows: replace echo ':windows:M::MZ::/usr/bin/wine' /proc/sys/fs/binfmt_misc/register with grep -qs magic 4d5a /proc/sys/fs/binfmt_misc/* || echo ':windows:M::MZ::/usr/bin/wine' /proc/sys/fs/binfmt_misc/register replace status)[[ -e /proc/sys/fs/binfmt_misc/windows ]] echo Wine Registration enabled || [[ -e /proc/sys/fs/binfmt_misc/windowsPE ]] echo Wine and Pnet Registrations enabled || echo Wine Registration disabled ;; with status)if [[ -e /proc/sys/fs/binfmt_misc/windows ]]; then echo Wine Registration enabled; else if [[ -e /proc/sys/fs/binfmt_misc/windowsPE ]]; then echo Wine and Pnet Registrations enabled; else echo Wine Registration disabled; fi; fi;; 3. Make sure they're both enabled: chkconfig --level 2345 pnet chkconfig --level 2345 wine Since pnet is at 80/30 and wine is at 99/10, pnet will be installed first, and wine will avoid stepping all over it. If you later disable pnet, wine will work as it always did. The only issue is that if you manually start (stop) the pnet service, or (un)register pnet directly, you'll need to restart the wine service, but I don't see any easy way around this. I played around with a pnet script that handled this. On starting, it checked whether wine was registered for MZ, and if so, unregistered it; on stopping, it checked whether wine was registered for PE, and if so, registered it for MZ as well. But this seemed like too ugly of a hack for too little benefit.
[Cooker] New/fixed packages: gtk-sharp-0.8-1mdk, mono-0.23-3mdk, gnome-db-0.2.96-7mdk
Gtk# is a project to provide a GUI for portable ICS/.net applications, built with either mono or pnet (or Visual Studio.net, or that matter). Since WinForms support isn't there yet in mono, and may never be there for pnet, you pretty much need either this or Qt# for now if you want to do .net on linux. In fact, even when WinForms support is done, you may prefer Gtk# (or Qt#) because you're more comfortable with Gtk+/Glade (Qt/Qdesigner) development than Win32/VS, or because you want a truly free solution. Gtk# should work with both pnet and mono, but I've only tested with mono, and only building a simple Hello World app. I based this package on the Redhat 0.7 package from the Gtk# website; the description seems a little odd to me, but I left it alone. In building Gtk#, I discovered problems with two existing packages, so I've submitted fixes for those as well. 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. 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#).
Re: [Cooker] Post 9.1 Wishlist
On Tue, 2003-03-18 at 19:24, Austin wrote: 1. Spiffy new sounddrake. If I knew perl, I'd do it myself, but alas... I'd like to see a more intuitive setup. What card is detected? What drivers do you want, alsa or oss? Do you want a sound daemon? I have no drivers, but I want to use remote sound via esd/nas/etc.? I want my sound server to accept remote connections from any machine my X server allows connections from/has a current connection from? I want both drivers for both/all my detected soundcards--this one is card 0 (primary), that one is card 1, etc.? 2. Spiffy new fontdrake. It's looking a bit dated; it's not all that easy to use; it would be cool to have more features. I'm sure someone can think of something to do to it. It should let you view uninstalled fonts and select them easily from the same interface. It should have options to show a complete font table (like gfontview). It should have more robust error-handling (if some step doesn't work, like converting a TTF to PDF, tell you what went wrong, and ask whether you want to install whatever worked or not). Instead of just saying You can still install the normal way, it should tell you what the normal way is (especially useful if there was any error). 11. Superchaged applications. While I'm all for an rpm system and i586 optimization, there are a few applications that REALLY suck as they are. ATLAS, transcode, and mjpegtools come to mind. They are rediculously slow. Narfi has some benchmarks I think. Some options are: a) put athlon/P4/mmx rpms on club b) put athlon/P4/mmx rpms in unsupported c) someone write a script that will rebuild them locally with more optimization d) someone write a script that will rebuild any srpm locally for local architecture I've suggested (d) a few times to Deno and others and got quite rude responses. I think it might be a cool feature... definitely media worthy. You could install a stock distro, then rebuild anything resource-heavy (XFree, ATLAS, transcode) for your local architecture with no rpm or tarball knowledge. It's just an idea. Options c) and d) are pretty easy--if your local architecture settings actually specify what you have, anything you build will be optimized appropriately, so the only script you need is rpmbuild -ba or --rebuild The problem is urpmi. First, urpmi has to know that you want P4mmx if possible, 586mmx if not, plain 586 as a fallback. That's not too hard--but how does it choose between 1.4.1-2mdk.p4mmx.rpm and 1.5.0-1mdk.586.rpm? If I have mything-1.4.1-2mdk.P4mmx.rpm installed, and mything-1.5.0-1mdk is on one of the mirrors, what does urpmi do?
Re: [Cooker] Re: Post 9.1 Wishlist (9.2 ??)
On Wednesday 19 March 2003 03:21, David Walser wrote: Could the application itself just have runtime detection of CPU features, so you can compile SSE/MMX support in the one package, but it won't try to use it on CPUs that don't support it? I think mplayer does this, and didn't use to. This would be fine if every application did this, but many don't--and won't. To make runtime-selected SSE/MMX work as efficiently as compile-time is a lot of work (you obviously can't switch on a runtime flag in the middle of a tight loop). There are a variety of ways to do this, but none are as #ifdef'ing around the code, so that's what most developers do. Also, there are cases where the there's no explicit code in the application to take advantage of SSE/MMX, but the optimizer can find some use for it anyway. There's obviously no way to switch around this at runtime.
Re: [Cooker] Re: [Contrib-Rpm] kernel-multimedia-2.4.21.0.16mdk-1-1mdk
On Sunday 16 March 2003 14:00, David Walser wrote: Austin wrote: On 2003.03.16 13:16 Danny Tholen wrote: yes this is annoying. Lilo labels are limited to 10 chars IIRC. It's more than 10; I can't remember how many exactly, but I can tell you that 2.4.21-14mm-cus fits, but linux-2.4.21-14mm-custom does not. Which brings up a point: Maybe it's worth dropping the linux- prefix from the labels of extra kernels? I realize that it might be a little unclear for some users. (On the other hand, what else could it 2.4.21-1mm be? I can't think of any OS that has a 2.4 release in the recent past (how long ago was OpenBSD 2.4?). However, if Mandrake is going to use lilo, and lilo has a limit of somewhere above but not too far above 10 characters, maybe isn't it much worse to have the install scripts add a label to lilo.conf that stops lilo from working? Does grub suffer the same disability? Most other distros use grub by default. Why don't we? Does most other distros mean Redhat? I know they switched not too long ago (7.2, I think?), and SUSE around the same time (8.1), but I think most of the others--including distros as diverse as Conectiva, Slackware, and ASP--and still using lilo. Is this because they're being overly cautious? We did for one release, hopefully we never do again. It was a disaster and a support nightmare. In my experience, grub has some cool advantages when trying to recover a machine in disarray if you can't boot off CD or floppy; other than that, most of its advantages don't really matter. I know, grub can handle more complicated setups, but lilo works fine for me on a machine that boots linux, FreeBSD, and Windows XP of a pair of hardware RAID arrays, and another that boots linux, BeOS, and Windows98 off an 4-channel IDE setup; how much more compicated am I likely to need? I'm sure there are some situations where grub works and lilo doesn't, so it's good that Mandrake supports it, but I don't see any reason to switch to grub as default.
Re: [Cooker] Re: War
On Saturday 15 March 2003 18:36, Leon Brooks wrote: On Friday 14 March 2003 03:56 am, Francisco Alcaraz Ariza wrote: 1) I don't think that American people that would buy Mandrake won't buy it now, because all the American not Windows user were antipatriotic before. If you are a good American, you must use windows, musn't you? This was basically my point, but I've been thinking about it. Many idiots of that type _do_ buy linux. In fact, I've been in the position of advocating linux to corporate management, and I don't know how I forgot this So, Jean-Michel Dault's original posting is relevant; people in the position of trying to sell Mandrake to management need to find answers to, Let's go with Redhat, because it's made in the good ol' US of A. On another subject: No. It's a risk to national security. http://www.eweek.com/article2/0,3959,5264,00.asp From the article, Microsoft plans to withhold one protocol and a few APIs because of security issues, and: The protocol, which is part of Message Queuing, contains a coding mistake that would threaten the security of enterprise systems using it if it were disclosed, Allchin said. This was almost a year ago; more than enough time for some cracker to reverse engineer the protocol, discover the vulnerability, write an exploit kit, and distribute it to millions of codezkidz. So either the exploit wasn't easily usable, or, in this case, obscurity bought Microsoft just enough time to get a fix out before the vulnerability was found. Either way, they got away with it this time; I don't think this proves that using Windows is unpatriotic. Also, pushing the argument that the US government shouldn't be using any OS that could have security issues would be a bad idea for linux. IIRC, the government commissioned a thorough security audit of OpenBSD, and a large share of the funding for OpenBSD's security RD comes from DARPA, USAF, and NSA--so if they're going to go with a different OS because of security issues, it's not going to be Mandrake.
Re: [Cooker] Re: [Contrib-Rpm] kernel-multimedia-2.4.21.0.16mdk-1-1mdk
On Sunday 16 March 2003 09:51, Adam Williamson wrote: It's just that the kernel is an important package, and I think it gets a bit confusing if there's one that's getting quite a bit away from the other five versions...sure it's in contribs, but kernel is so important maybe it needs stricter control than most contribs packages... So maybe there should be an official -mm kernel, and a separate -dt kernel in contribs? If that were the case, I think a decent number of multimedia users (given enough information) would use the -dt kernel, while almost nobody would use the official -mm kernel, at least not enough people to be worth the effort to make yet another kernel build or the disk space/bandwidth to distribute it. In other words, in my opinion, things are fine as they are now. By the way, one minor problem with the -mm kernel (at least as of the 2.4.21-0.14mdk release): If you build a custom kernel starting from kernel-multimedia-source, the label it tries to install in lilo is too long, and you get a lilo error; you have to go in and edit lilo.conf manually. Since I always rename and reorder all my kernels anyway, I'm not complaining--and I doubt anyone who builds and installs custom kernels, especially starting from anything but the standard kernel source, is likely to have a problem editing lilo.conf.
Re: [Cooker] OT: War, french fries and Mandrake Linux
On Thursday 13 March 2003 11:59, Jean-Michel Dault wrote: There has been a lot of discussion about Americans wanting to boycott french products, and some mails of people that said they wouldn't buy Mandrake Linux because of that. Imagine the nerve of a democratic government doing what its people want, and what nearly every other democratic government in the world is also doing! They must be punished! Weren't the French paying anything to Chile in 1973? Lafayette, we are here--to kick your ass! Anyway, people aren't boycotting french fries and french toast, they're just renaming them freedom fries and freedom toast. So why not use the same trick? Mandrake is not a French company, but a freedom company! (And what could be more appropriate for a free software distributor?) Ah, I remember the first girl in junior high who let me freedom kiss her On a more serious note, will pushing Mandrake as a cooperative world effort (just like the UN) make the jingoist dumbasses any happier? I think people who will refuse to buy Mandrake Linux because Mandrake is in France, and some idiot from Ohio told them to stop buying anything in any way associated with France, aren't going to be swayed by this effort. and I am Quebecois ;-) Well, Quebecois sounds french enough for me, you frenchy person you. I say we drop that spiffy new MOAB on your head and take out Montreal. And Paris, Texas. And New Orleans, Louisiana--actually, all of Louisiana (Bienvenue en Louisiane? Bienvenue en mort, frenchy!). And Liberty Island in NYC, with that damn frenchy statue. And Baltimore, and any other city whose major streets have frenchy names like Orleans and Lafayette. And DC, since it's built on that frenchy city plan.
Re: [Cooker] Re: War
On Thursday 13 March 2003 15:40, James Sparenberg wrote: if it's daddy it's George Bush If it's the son it's GeeDubya or Das shrubenmeister Or, if you're from Iraq, they depict him as a Ferengi (from Star Trek) named Dub. (And I never realized DS9 was so popular in Iraq until I saw their editorial cartoons) And now, to celebrate the Scottish figurehead government's decision to go along with Germany and France in opposing the war, I will go to McDonald's, and get myself a Hamburger and French fries.
Re: [Cooker] Reinventing the Debian (was: 9.1...Delayed)
On Sunday 09 March 2003 01:53, Michael Scherer wrote: To give a simple exemple, we still can choose SGI and HP in the hardware section. Well, you actually can still use SGI hardware with Mandrake, since the last couple generations of SGI hardware were standard Intel boxes with standard video cards More seriously: The force of Debian is not in the 3 distro approach. They use a special bug reporting tool, not a web interface. This sucks, IMHO, but, on the other hand, you need to know how to report a bug, and, people don't post kde don t work bug. I'm not sure whether or not the 3-distro approach is important to the strengths of Debian, but I suspect that it's part of their weaknesses--in particular, the fact that their stable releases are usually far behind most other distros (not just Mandrake, but everyone). The more I think about it, the more convinced I am that it's not appropriate for Mandrake, at least not the way they do it.
[Cooker] New contrib package: wshaperx
I realize that the timing on this one is even worse than on the last batch, and I obviously don't expect anyone to do anything with this until after 9.1, but I figured I'd upload and announce it anyway. Should I re-upload and re-announce these packages after 9.1 comes out, or will someone get to them then? (Since I never contributed anything to Mandrake until very recently, I don't know much about the process and how it's disrupted at release times). The wshaperx package is a reworked version of the wondershaper package. Wondershaper makes traffic shaping easy (well, easier); wshaperx makes wondershaper easy (well, easier). There's a decent chance that the people at lartc.org will take what I've done and integrate it with their work better than I have; I'm still waiting for a response. Until then, if you want it (and it hasn't appeared on the contrib mirrors yet), email me.
Re: [Cooker] [Bug 3026] [xmms] xmms can't work with KDE
No, that's not the solution. XMMS does know how to work with arts--you just have to use the arts output driver, rather than whatever comes selected by default (I think it's OSS?). When you launch XMMS, go to Preferences (Ctrl+P). On the first page, in the output driver combobox (the lower half of the window), select arts instead of whatever's already there (oss, I think?). Since Mandrake uses KDE with arts as the default desktop setup, maybe Mandrake's XMMS package should default to arts output? On Sunday 09 March 2003 09:49, rolfpedersen wrote: 18:49 --- What helps wrt this conflict is to set the autosuspend timeout to 1 second (default is 60 seconds) in kcontrol Sound Sound System. I don't know why the default is so high and have always set it down to allow such programs to start with less delay. There might be some need for it in some usage or it might be better to lower the default to avoid such problems as this. assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: If an event from konqueror used the sound device (error message, ...), it's not possible to use xmms (couldn't open audio). artsd use the device and so xmms can't use it.
Re: [Cooker] The Mandrake Audio Workstation
On Sunday 09 March 2003 10:19, Benjamin Pflugmann wrote: - In section 3, you may want to mention another advantage of Mandrake (of course, it's not exclusive to Mandrake): That of this effort being possible. In other words, the current state is only possible, because contrib exists and there were people (besides Mandrake employers, who do a great job) who were willing to put time and effort to get the missing packages in. There's also the fact that because Mandrake is so spiffy and developer-friendly, many developers are using Mandrake themselves, so they build Mandrake packages right from the start. (This wasn't true even a year ago, and it's made it much easier for me to explain to people why they should choose Mandrake over Redhat or SUSE) - In section 6, setting up online software resources, for the uninitiated, it is not obvious that Mandrake Contributions section refers to what you meant with online before. Also, your mentioning of 95% of apps being there, immediate rose the question of where do I get the other 5%, which you don't answer. Either make clearer, that those 5% are only apps I need, when I got to experienced user level, or say it in a way, that the question does not arises, or explain how to proceed for that 5%. 95% of the apps you will need are going to be on the CD's, or in the Mandrake Contributions section online. ... 95% of what you'll need is included with Mandrake Linux. At least one of these has to change; after all, if 95% of what you need is included, and 95% is included or in the Contributions section online, then 0% must be in the Contributions section online The problem is this: of the remaining 5% that aren't on the CD, 95% are available in Mandrake contribs. And then, of the still-remaining 5%, 95% are available through PLF. Of the even-stiller-remaininger 5%, 95% can be rebuilt from SRPM/built from source tarballs/converted from apt/installed using some custom installer package. Of the ben-stiller-show-didn't-remain-on-the-air-very-long 5%, 95% need a little work to get running on most Mandrake-based systems. And so on. The farther down the chain you go, the more there is to explain, the less it helps, and the less accurate is the idea that the apps you won't need until you're experienced are the apps that are harder to get Also, it's simply not true. For example, the most important part of the system, as far as the intended user is concerned, is kernel-multimedia, which is not included with a default Mandrake install. And 50% of what you need isn't available at all, because it doesn't exist, which is why you should contribute (seek out projects that sound interesting and test bugs for them, etc.). This is very important--but it'll also scare off much of the target audience. I think, all in all, the best solution is to just strike both 95% references, and say something like, The first step is to get Mandrake Linux. You can get the core... the first time, and, You will need to access the Mandrake Contributions section online. Then, if you think it's necessary (I don't), add a separate paragraph here saying something about how there are other sources for software, and new software is being created all the time, and as you go along, you'll continue to discover more, or whatever (in other words, hint that seeking out new software, getting it to work with Mandrake, helping in the development in other ways, etc. is something that'll come naturally and be fun, because if you don't scare people off, that is actually what often happens...). - In section 7, I like that (If you have to ask, you don't) part :-) But a link to some resource about SMP (in a technical dictionary?) would be nice, anyhow. - Use a UL in section 9d, to make that list stand out more. I agree, this does not to be just a tiny bit more prominent. Links to the appropriate pages would probably do the job just as well as underlining the categories, as well as being useful on their own. (Also, please move rosegarden from Score Editing to Sequencers.) - Is it intention that you don't mention PLF in section 9f? I think the description of other restricted software in the last paragraph, with a link to pclinuxonline, is good enough, since pclinuxonline has a quite-visible link to PLF themselves. On the other hand, since this page isn't hosted in the US, it might be worth mentioning PLF directly--after all, for Canadians, some of what's in PLF actually is free Also, the link to pclinuxonline is broken (it links to w.pclinuxonline.com instead of http://www.pclinuxonline.com;).
Re: [Cooker] The Mandrake Audio Workstation
Austin: Please ignore the preceeding rant. You think it's so bad almost living in America, try actually living here (I especially love hearing Albertans complain about their American-style health care system) I chose not to mention PLF so Mandrake or anyone else could reference the document if they so desire, without modification. Guillaume Rousse: Do you really think mentionning it would prevent anyone else to refer to the document ? Even if using libdvdcss is prohibited in USA, you still can discuss of it directly, or refers to someone else discussing it. Yes, but you cannot provide a direct link to libdvdcss. You can provide a direct link to a page that provides a direct link to libdvdcss--unless either the link or the linked-to page is clearly for the primary purpose of getting libdvdcss. Sites have gotten into trouble for being only one link away from porn, warez, and DeCSS sites, and the two-link rule of thumb is a good way to be safe. (Ah, America, the land of free speech--but I won't criticize, because if you ever say or even think anything bad, the terrorists have won) Of course if Mandrake links to his page, they already have that extra-link safety--but if they want to host his document directly, they don't. And, more vaguely, not mentioning PLF in his document allows Mandrake to host it if they want while maintaining their plausible deniability related to PLF (Sure, we assumed that some of our users would find and use that software, but we had no idea that there was some kind of organized effort, much less that this effort was part of the reason some people chose our distribution...). Anyway, PLF is easy to find if you go to pclinuxonline looking for Mandrake RPMs; anyone who can't get there will probably not be able to add URPMI sources anyway
Re: [Cooker] The Mandrake Audio Workstation
Two more things: First, I forgot about Muse (because I couldn't the previous version to work...); it should be listed along with rosegarden under sequencers in the other software section. There are, of course, plenty of programs you don't mention, with good reason, but I think that Second, although this probably doesn't matter for your FAQ, forget what I said about both VST-on-linux projects failing; apparently, there is now a working VST-LADSPA wrapper (oh frabjous day!), and it's available for Mandrake in Thac's audio packages (http://rpm.nyvalls.se/sound9.1.html).
Re: [Cooker] The Mandrake Audio Workstation
On Saturday 08 March 2003 09:19, Austin wrote: Well, since 9.1 should be out next week, and most of the kernel/alsa/jack problems seem to be cleared up, I'd like to present the howto for setting up a digital audio workstation with Mandrake 9.1. ... see http://groundstate.ca/mdkaw.html This is very cool. The main reason my Mac still exists (and isn't running linux) is for music. I'm pretty sure the day is coming when I can put it in a closet, and your document helps bring that day closer--so thanks. And now, here's probably more feedback than you were looking for One global comment: this is geared toward someone who wants to run a home recording studio, and it does an excellent job at explaining that, but there are at least three other tasks it barely touches on: 1. Music composition. You can't replace a Mac running Cubase or Logic with linux software yet, but Rosegarden is getting there. It would be good to describe Rosegarden (you list it as a score editor--which is all 2.x was good at--but that's it), and to mention what they can and can't do with linux today. 2. Live music. You can already bring a linux laptop or rackmount on the road if you just want to use it to play backing tracks and/or run a single software synth (although again, you can't yet do everything many musicians are doing today with Cubase or Logic on a Powerbook). 3. DJ'ing. A linux laptop can plug into a mixer in place of a CD deck or turntable easily, and this might be worth mentioning (although probably anyone who's thought of this knows that xmms will do the job as well as WinAmp). But ideally, you want to replace the mixer, too. A two-output soundcard can provide your main and monitor, and all the mixing can be done in software. You can do everything you need today in Windows (even including external controllers packages with the software, in some cases), and linux should be there very soon. 4. Post-processing, 5.1 mixdown, integration with video, etc. Linux can't replace Nuendo (or ProTools) yet for this, but it probably won't be too long. I think the focus on recording is appropriate, if only because that's what linux is best at. If you're in a band makes music without a computer, and wants to record that music, linux today can do that (nearly) as well as MacOS or Windows, for less money, and almost as easily. I'd like to see a brief section on what linux can't do yet, a little more on other audio-related stuff you can do with linux, and maybe a different subtitle (A guide to creating a professional quality audio recording workstation with free software would get the idea across). One comment on sound cards: Really, most sound cards offer adequate sound quality to do home recording. If you're doing everything inside the computer, this is true. However, if you're going to have signals going in and out, it's not. First, most sound cards handle 44KHz 16-bit sound, while the computer can work with (say) 96KHz 32-bit sound. You cannot tell the difference between the two (many people claim they can, but try blind tests on them and you'll see the truth). However, if the music is downsampled repeatedly, especially if it's converted between analog and digital as well, you can tell the difference in the end. Also, if you're planning to record to, say, both CD and DAT, downsampling from 48K to 44K (or vice-versa) has noticeable effects; downsampling from 96K to either, there's no issue. If you plan to do a lot of work with analog outboard gear (or if you use 96K digital outboard gear), consider spending more money on the soundcard. And here's where it's very important to verify the linux support for each card; most low-end cards works well on linux, but only a few high-end cards do. Also, if you have a mid/high-range video card, you may want to consider getting a heat-sink/shield for it. This has the added advantage of making your computer quieter and cooler. Now, one comment on outboard gear: If you're really serious, use as much outboard gear as you can. I disagree. You want to use as _little_ outboard gear as you can. Every pass through the D/A or A/D introduces artifacts. Every meter of analog cable, and every device/cable connection, introduces attenuation and interference. Professional studios have the experience, the space, the money, and the design freedom to eliminate interference far better than you'll be able to. And, unless you buy top-of-the-line equipment, the gear you use is going to degrade the sound itself. But everything you do inside the computer is perfectly loss-free. If your audio goes into the computer (through a mic or line in), then never leaves again until it's burnt on a CD (or whatever the final disposition), it will sound much better, for much less money and less work. Plus, there's an added advantage: You can use cheap gear for most of the process. You'll still need a good setup to hear it all while you're doing the final
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 22:00, Paul Dorman wrote: Or what about some kind of p2p solution? Where -light machines are networked to and updated from other -light machines across the net? Checksumming and other tools could be used to address security concerns. You know, I almost took a job working for a company that thought the time for this had come a year and a half ago Maybe it is more doable now, at least for open source software (you don't have to worry about how to bill people, how to force users to stay online whenever possible, etc.), but there is still a major project, and there are problems that nobody's yet solved. On the one hand, an open source project can just use an existing protocol (say, gnutella) rather than building something new from scratch, and doesn't need to worry about billing, etc. And just distributing SHA URI's on official mirrors would be enough to search for the file online and verify that you've downloaded the right one (and of course RPM signatures provide security on top of that). But on the other hand, where does the network come from? If you build a new p2p network from scratch, you need to get people online. Most users won't be connected to the network except when they're in the middle of their own upgrade. If you use, say, the existing gnutella network, you have the advantage that every Mandrake user who's using gtkg, qtella, limewire, etc. (assuming they've added their package repository to their p2p upload directory list) is available--but the disadvantage that most of the people on the network don't have the files you want. Either way, you'll probably still need mirror sites--and I'm guessing it's much easier to find someone who will run ftp, rsync, and/or http mirrors than finding someone who will attach their mirror server to either a brand-new p2p network or the existing gnutella network Oh, and I think that packages should be revertable on installed systems as well. Users should be protected against unstable software wherever possible, but at the same time they will demand the very latest releases. It would be nice to be able to downgrade through urpmi and the GUI tools (of course you can already downgrade today--just download and force-upgrade--but it's not as easy as installing or upgrading). If I try to downgrade kdebase, it would tell me you also need to downgrade kdelibs and kdegames and uninstall kdevelop, and (if I approve) it would go get the relevant versions of kdebase, kdelibs, and kdegames and so on. I think that being able to deal with the same package groups as the installer when upgrading, installing, or downgrading would also be helpful. A beginning user knows that he installed KDE Workstation, and wants to upgrade that, or that he skipped LAN Filesharing (or whatever that option is called) but now he wants it, but probably doesn't know what packages that involves. Maybe something like Microsoft's restore points in XP, but done right, would be useful as well. I mark a system restore point, then upgrade to the new version of Mandrake, install a bunch of new packages through rpmdrake, whatever; then, if it doesn't work, I just restore to the last point. Unfortunately, I think it would be even harder to get this right under linux than under XP. Anyway, I think that all of these ideas deserve looking into. Of course these kinds of suggestions always come up at the worst possible time, because that's when people think about them. Certainly you don't want anyone at Mandrake, or anyone who could be contributing to the 9.1 effort, putting much time into anything like this for the next few days. So, remember the ideas that are most important to you, wait until 9.1's out the door and everyone's had a little breathing time, then start a discussion when it's still months to go before the next freeze.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 23:40, James Sparenberg wrote: Do you honestly think one of the largest firms in the industry (who is now using our product) would like it if we told them We'll fix your bug when we get enough votes.. *sigh* Well, when you're doing corporate development, you usually bias things, something like one licensing seat, one vote, so the fact that your largest-by-far client is complaining about a bug pretty much automatically means that it has enough votes. But the principle is the same; a bug that's only affecting a few smaller clients is probably not going to get fixed right away.
Re: [Cooker] Peer to Peer Package Sharing (was Mandrake 9.1 Should be Delayed)
On Friday 07 March 2003 05:33, Vincent Meyer, MD wrote: On Friday 07 March 2003 05:22 am, Paul Dorman wrote: Andi Payn wrote: But on the other hand, where does the network come from? If you build a new p2p network from scratch, you need to get people online. We're already online! Just a matter of getting things started. Yes, many Mandrake users have a 24/7 connection (or at least a many-hours-per-day connection) with lots of bandwidth. But that doesn't mean that they'll all be willing to run a p2p server and share that bandwidth. First, there are potential security issues. Second, some people pay for every kilobyte of bandwidth they use--and those who don't still generally want to have all the potential bandwidth they're paying for available whenever they want it. (You could set up a traffic shaper where everything else has priority over the P2P system by default, but that's not exactly trivial.) Third, running a server takes CPU and memory. Fourth, you have one more port to open up on your firewall. Finally, any time you force people to provide resources in exchange for free software, the software is no longer free. So you'd pretty much have to make the default setting, Don't run the server, then try to convince your users to run it. I'm not saying it would be impossibly hard to do this, but you can't count on automatically having a huge P2P network running just because there's a huge Mandrake user base. There's also the fact that most users don't keep 2GB worth of packages (more, considering that you want to be able to find downgrades on the network) lying around their hard drives--they either keep them on CDs, or they download and immediately delete them (through urpmi/rpmdrake, or manually). If you searched my system, you'd find the six packages that I put together myself, and maybe a few others that are part of the urpmi I'm in the middle of. If you're really lucky, one of the rc2 CDs would be in my drive. I might be willing to host the whole distro for the good of the network (what's 2GB out of the 12 or so drives lying around different systems in my house?), but it certainly isn't anything that I'm already doing--and I think the same is true of most other users. Having a few high-bandwidth major mirror servers on the P2P network would make a huge difference, so the most important step is probably finding sites to host such mirrors. Would stealth.net, mirrors.org, etc. be willing to do this? I guess the only way to find out is to ask them Trying to get users to contribute their own bandwidth, storage, and other resources (whether through community spirit, discounts on Club membership, or whatever) could be a long-term goal, but I don't think it'd be enough to get the system started. MandrakeSoft should provide the top level server, which could then be used to authenticate packages and such, too. A real P2P network doesn't have a top level server, but you're on the right track--they can provide a simple webserver that just provides the SHA URIs (in fact, they could be custom-protocol URLs, and Mandrake could configure the web browsers to send that protocol to the P2P upgrade program). An advantage of this kind of network is that MAYBE a big hard disk isn't required anymore. I have a dual boot laptop, and the two partitions I have are both over 95% full. Can only go so big on the drives that will fit in this machine! With a P2P, could search for the roll-back package, and with enough users out there probably find it. Except that if you keep fewer packages around because they'll be all over the network, so will everyone else, so those packages actually won't be all over the network The categorisation thing is a hard problem I think. What relevance is there *really* in choosing a KDE workstation or a GNOME workstation? If I use KDE, I want to be able to upgrade all of the KDE Workstation packages that I installed in one fell swoop. If the categories have any useful reason to exist in the installer, I don't see why they shouldn't exist in the upgrader. Maybe something like Microsoft's restore points in XP, but done right, would be useful as well... ... Unfortunately, I think it would be even harder to get this right under linux than under XP. But I disagree that it would be harder to do it under Linux than under XP. We have openess, community, and package management systems! Yes, but they have a monolithic OS that's developed almost by a single team, they have control over what updates are available, and they have the freedom to get it wrong the first time and then spend two years getting it right without going out of business Think about it this way: Under XP, you either install SP1, or you don't; under Mandrake, there are an unbounded number of upgrade paths. XP just tracks files replaced in or removed from the C:\Windows hierarchy and changes to the registry. Under linux, you'd probably
Re: [Cooker] kdemoreartwork proposal
On Friday 07 March 2003 17:34, James Sparenberg wrote: Just a side thought...if kdeartworks is wanted... could the program xemacs (Note emacs-X11) be swapped out. Since emacs-X11 is the replacement for xemacs with superior functionality I'm told this might be the time to take a look at some of the unused legacy here. The simple answer is that no xemacs devotee is going to accept eliminating xemacs for GNU emacs (the emacs-X11 package), and no GNU emacs devotee is going to accept eliminating GNU emacs for XEmacs, and even thinking about it quietly in a locked room could spark a holy war If you want to know more about the split, start at http://www.xemacs.org/About/XEmacsVsGNUemacs.html and go as far as you're interested from there. It's an entertaining story with a long history (and I'd love to know whether it changes your opinion of Richard M. Stallman--and, if so, in which way). If you're interested in the practical differences: Frankly, for most users, nearly anything you're going to want to, you can do just as easily in either one--in fact, both of them can even run most of the others' scripts. But this hasn't been true for that long--before version 21 of each, there were definite areas in which each one was clearly superior, and many more areas in which they were just very different. And if you're not using a real *nix/X platform with a decent packaging system, there are still clear differences. And even today, within the *nix world, a fan of either one can point out a whole list of superiorities in their Emacs of choice which will sound very convincing to a halfway-knowledgeable outsider. If you're just looking for a non-controversial way to free up space on the Mandrake CD's, look elsewhere.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 04:47, Thomas Backlund wrote: Now there is no way for MDK to address this problem, as it should be adressed by nVidia, since they keeps the specs/driver source well guarded... ;-) We'll have to try to make the best of what we have, and hopefully nVidia will roll out new drivers for MDK 9.1 I agree. This sorry state of affairs is more a reflection on nVidia. Their drivers are clearly more fragile than they'd like us to believe. They're attempting to prove that their closed driver model provides at least as good results as open source driver development, and the only conclusions that the linux community can draw are that (a) they're wrong, and it can't be done, or (b) they're right, and it's possible, but they're not very good at driver development. Hopefully the end result will be a lessening of the pro-nVidia slant of the linux community, leaving room for someone else to come in and try to do it better. It should be much easier for someone at ATI, Matrox, or some other company to get more resources for linux development if it becomes obvious that nVidia's position isn't as strong as they pretend.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 08:33, Austin wrote: On 2003.03.06 10:43 Buchan Milne wrote: IIRC there were beta ISOs more than two weeks ago ... True. But my point was that I'm sure some people download a beta, report a bug, and then wait for the next beta to see if it's fixed. They could just as easily (and more efficiently) keep their initial install up-to-date with urpmi, and track their bugs every few days. It just seems to me that people are really stuck in the idea of ISO's because they've never known otherwise. And there's not much that Mandrake can do about this. The reality is, Mandrake is ahead of the pack. In fact, a large part of the reason that I chose Mandrake--and a large part of the reason I was and have been happy with my choice--was because I could install 8.0, then immediately start updating packages much more easily than with Redhat, SUSE, etc. In other words, the current system, especially the way Cooker is managed, works better than anyone else's. But, at the same time, because Mandrake does such a good job attracting Windows users--people who are used to getting Microsoft's new release every 3 years, and then only minor patches until the next one--many Mandrake users have long-standing bad habits; they don't understand that when people release early and release often, the monolithic release that you buy in a store or download as a set of ISOs isn't the whole story. In other words, it's hard to leverage large numbers of Windows converts into a large pool of useful linux bug testers, but certainly the distro (and the company) is better off with them than without them.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 06:17, Adam Williamson wrote: If the problem is contractual obligations, perhaps the 9.0 experience ought to indicate that such contracts should not be made. How do you propose that Mandrake release their software, then? If they wait until there is a stable release before signing contracts, it will be at least a month before that release hits the shelves, and even longer before most of the advertising supporting that release appears. And that's assuming that they have good relationships with everyone involved (and are willing to pay for rush work in some cases). You can't just call someone and say, OK, our release is ready, and get it in stores the next day. Now, in the long run, they'd still get out the same number of releases per year, it's just that there'd be a gap of a couple of months when they first switched to this new strategy. That doesn't sound too bad, but think about what it means--it means a couple of months with significantly reduced revenue, which isn't such a great thing for a company in Mandrake's financial situation (or, really, any company). Plus, this means that the releases that people buy on the shelves would no longer be up-to-date. Part of the reason that people choose Mandrake over, say, Redhat is that Mandrake usually has state-of-the-art packages. To people who switch from other distros, this is a huge difference. A friend of mine once asked, Why should I bother upgrading to the new version of Redhat if I'll still have to install gcc and KDE myself to get recent versions? I was able to point to Mandrake and say, Look, they have them. Why not switch? He did. To people who switch from Windows, this may not seem like as big a deal--but it still makes a difference. For example, part of the reason that Mandrake 9.0 looked good to Windows users than the other distros was KDE3, and part of the reason it worked well for them was konqueror/galeon, evolution/kmail, and the various office packages--all of which had only recently become good enough to sell a Windows user. In other words, Mandrake can't afford to have major releases that are two months out of date. But they can't avoid this unless they pre-schedule their releases and sign these kinds of contracts. Of course some companies sign even larger contracts and start even larger advertising campaigns and then slip releases by months, anyway (Windows 97, anyone? Rhapsody 1.0?). But most companies can't afford to pay two or three times for each release, keep the release-time ad blitz up for months on end, and fight the bad PR. Apple can just barely get away with it; Mandrake certainly couldn't. The way that software is released today stinks. It's bad for Mandrake--but it's also bad for Microsoft and Apple and Redhat, and for Symantec and Microprose and Adobe. Mandrake refusing to play by the same rules would not affect the system, it would only hurt Mandrake.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 19:08, George Mitchell wrote: Andi, there is a solution to this problem. That is to maintain a stable version of cooker. Do the actual work of upgrading and fixing various components offline, and merge them into the stable cooker tree only when they have been thoroughly tested. In the mean time continually use bugzilla to QA the stable cooker tree itself. As it is, cooker is a collection of a gazillion efforts all attempting to take place simultaneously on the same codebase, and all attempting (or forced) to come to maturity at the same time. And even though the software is modular, there are cases where a problem with one component can jeoperdize a timely fix for another. The various efforts need to be delinked and individually debugged on a stable cooker. The existance of a stable thoroughly QA'd cooker would mean that Mandrake could pull the cord for a release at any time without risk of unforseen headaches. Cooker the way it works today--a not-quite-stable, not-quite-integrated repository of version upgrades and new packages that may get into a future version of Mandrake--is one of the major advantages of Mandrake over the other linux distros. I wouldn't want it eliminated. I like the fact that I can usually get a Mandrakized package of the latest version of XXX quickly after it's released, and usually it works--even though occasionally there are problems. The fact that I can't get that with any other distro is a big part of the reason that I use Mandrake. And no development project can stay in release mode all the time, without separate branches for blue-sky/experimental/unstable work. So really, you'd need to split Mandrake development into three branches instead of two: 9.1 upgrades, a mostly-stable pre-9.2 Cooker, and a like-today's-Cooker experimental branch, with solid QA on both of the first two branches. In fact, the first two could share much of the same team: close to a release, both would be working primarily on getting 9.2 ready to go out the door, while shortly after a release, both would be working on figuring out what can be hammered into 9.2 as an update and what has to wait for the future. And this does in fact work for some other projects (including Debian, I believe). But still, it would require more Mandrake resources, and more user involvement, than the current system. And, while you would probably attract new people to the Cooker effort if it were a more stable system, you'd also find that many of the people who help today would prefer to work on the blue-sky branch. A compromise might be to do a QA'd sub-release of Cooker every two months, rather than every six months. A single team can work on a project with release dates this short, spending a couple of weeks in freeze every two months. I think most Cooker users would put up with these freezes in exchange for an even-more-usable Cooker. And, more importantly, both Mandrake's team and the user community would have more experience getting together a solid release; it would require less work to tie together two months' worth of development than six; and there'd be a solid way to back-track any subset of the distro, if necessary, without going all the way back to the last major release. But I'm not sure the system really needs to change. Is it really working that badly? The consensus on this list seems to be that there are major problems with the releases. And, to be honest, people I know who've been using Mandrake for a long time complain that each release is worse than the last. But people I know who've switched from other linux distros, or from Windows, have mostly been happy with the stability of Mandrake 9.0. (True, people who came from MacOS or BSD had lots of complaints, but you can't make those people happy)
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 19:16, Timothy R. Butler wrote: What about using the three tier approach of Debian? New stuff goes in unstable, after a few weeks of qa, it goes into stable Cooker (that is, testing), and then the releases are stable. As it stands, Cooker at any particular moment can be anywhere inbetween those three stages. I guess I should have waited a few more minutes before replying, because you stated this alternative much more clearly and succintly than I did But I still think that the current Cooker system is actually useful. I have a Cooker-based workstation that's stable enough to rely on for all of my daily work. I have a server that I wouldn't put even a stable Cooker release on. I don't really have much need for something in between. It may be that I'm an anomaly, and many people would use that intermediate distribution; if so, it would probably be worth the extra effort to migrate to a three-tier approach. If not, it would be extra expense that may not buy anything useful. That might allow more people to run Cooker testing even on production systems, as they would know while there might be bugs, it generally wouldn't ever be just plain broken. In such a situation, I'd probably opt for testing over the stable release. According to the headers, you're using kmail 1.5, which I don't remember being the version in 9.0. If you're already using Cooker for your daily email use, doesn't that say something? (And if I'm wrong, please feel free to call me an idiot)
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Wednesday 05 March 2003 14:37, Jason Komar wrote: On Wed, 2003-03-05 at 15:22, John van Spaandonk wrote: And me On Wednesday 05 March 2003 22:40, N Smethurst wrote: I realise that I am a relative minnow here, but I nevertheless wish to express my agreement with Tim. I'm glad someone has expressed what I hesitated to say. Le Mercredi 5 Mars 2003 22:07, Timothy R. Butler a écrit : Is it worth risking Mandrake's future as a whole to get this distribution out by mid-March? I just don't personally see that as a realistic date when I'm using RC2. Mandrake developers are amazing people, but I still can't believe all of these problems can be fixed in just nine days. To me, RC2 seems more like a beta release and not a release candidate. I am in full agreement as well. The quality of the release is paramount. Mandrake has a reputation of being a good distro. for people who want to switch from Windows. Those people expect it to work out of the box with a minimum of bugs. I think this is also important for those who switch from other distros. I've managed to convince a good number of RedHat, SUSE, and even a few gentoo and debian users that Mandrake makes more sense for them. The library policy (You mean I can have both versions of XXX at the same time without force-installing and manually moving files around? Well, I guess I can use RPM after all!), the up-to-dateness and completeness of Cooker contribs and PLF (I spent weeks trying to get my Win32 AVI codecs working under SUSE!), urpmi, 586 builds, etc. are the features that convince them. But when they try it out, the first comments I get are always things like, Wow, I didn't know KDE looked this spiffy! or The installer figured out the DHCP for my LAN/cable modem/etc. automatically, and downloaded updates even before I got in and tweaked everything manually! The problems people are reporting will be just as bad for these kinds of users as for Windows users trying linux for the first time. However, that being said, I'm not convinced these problems can't be fixed in time for a release. We're talking about a small number of bugs that, while serious in their effects, appear to be small enough to knock out in a week. For example, the fact that the browser starts up with no homepage is pretty terrible--but it's just a matter of changing the default homepage from the indexhtml-9.0 location to the indexhtml-9.1 location. The kernel/driver issues are bigger, but if worst comes to worst, the kernel can always be rolled back, can't it? I remember being given a choice between two different 2.0 kernels in a linuxppc distro, because the newer one didn't work on some hardware. Would it be so terrible if you got a message saying, kernel 2.4.21 may have problems with some of your hardware; OK to install 2.4.19 instead? Meanwhile, Paul Dorman's idea of sub-distributions is interesting, but I think there's a better solution: Provide, in addition to the 3-CD distribution, a mini version that provides just enough to get you up and running and install other packages. You could download, say, a 150MB ISO for English, or a 180MB ISO for some other language (if there were people interested in maintaining a mini-distro for that language), instead of 2GB with everything. You'd have a basic KDE desktop only, everything needed to get on a LAN or cable/DSL connection, all of the packaging tools, the core development packages, and some of the setup/configuration tools, but few applications, no servers, etc. Then, provide an easy way to pull in groups of packages. Each of the groups you can choose in the installer would be available, and would install the exact same packages--except that it would only have to download the appropriate language, and it would download the most up-to-date version, from the mirror you chose. Even simpler, you could allow running that tool as part of the installation process. An alternative solution is the way linuxppc used to work a few years back. You download and burn an 80MB ISO that contains the installer, which can grab packages off a mirror instead of off a CD. (In fact, I never even burned the CD; they provided MacOS-based and linux-based installer bootstraps so you could just leave the .iso file at the root of an HFS or ext2 partition; that was nifty.) Making this fool-proof is difficult, but making it work 95% is easy--and good enough for the intended audience: people who know Mandrake, know what they want, and have broadband connections. I think either would provide everything Paul's looking for, and be very easy to put together. In fact, making a mini-distro out of the full 9.1 is something a single user could easily do shortly after 9.1 is released. By the way, as things are today, you can just download CD 1, install a bare-minimum configuration, then rpmdrake/urpmi all the packages you want off the net. 650MB is still pretty big, but it's
