[Cooker] Re: Problems booting with ext3 for root partition
Svante Signell posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 06 Nov 2003 09:12:23 +0100: > The long thread on 'kernel 23mdk panic' seems to be related to my problem. > Has anyone made a summary of conclusions made so far? Which kernels are > known to boot properly, with and without initrd? I compile my own kernel from kernel.org sources, so haven't been following this real closely, but AFAIK, any of the Mdk kernels work if ext3 support is compiled directly into the kernel, rather than as a module. I haven't been following it closely enough to know which kernels work with ext3 as a module. with or without user recompilation. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Interesting KDE stuff - IRKick
Vincent Meyer, MD posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 06 Nov 2003 00:30:23 -0500: > Loaded a bunch of kde updates, and there was a new icon in the kicker tray > - IRKicker. Looks like some kind of IR remote control thingie. Hmm.. > Right click and select to configure, and nothing happens. Right click, go > to help, ask helpcenter for the irkick handbook.. not found. Brings up > the help center, but no info on the app. I can't confirm this since there's little reason in my updating to the latest Cooker right now given that I'll be installing amd64 versions in the next few days (my dual Opteron hardware upgrade is scheduled to arrive later today, YEA!!), but I'm guessing that's part of the new KDE 3.2 betas Laurent has been putting out. If so, it's quite likely there IS no documentation for any new functionality, yet. I remember this was the case with early betas of 3.0 and 3.1.. However, given your description, it sounds indeed like an IR tray applet, likely pretty similar to the MSWormOS idea that's been around since W98, anyway, IIRC. I've always run desktop systems (laptops are in general to expensive and not upgradable enough for my buck), but I've seen the applet on friend's laptops. Basically, all it is is a visual display of the status of the IR serial port. When an IR printer or other such IR enabled device comes within range and a link is established, the MSWormOS tray applet normally plays a sound, and changes the icon to show two devices with a beam between them. When the link is broken, another sound, and it goes back to the single port beaming IR icon. There's little interactivity, except that IIRC right clicking on it brings up a configure option which would be the same properties display for IR available from the control panel applet. My guess on the KDE implementation is that they will have something similar, but at this point, the kcontrol IR applet isn't available or isn't configured right (someone reported they had no kcontrol entries at all, with one of the first Mdk beta versions!!), so the functionality isn't there and choosing that option does nothing, as you described. However, if you've a laptop and something suitable for communication with it via IR, you can probably test the link notifier functionality, and see if I'm right on that. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: FHS 2.3 (fwd)
FACORAT Fabrice posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 05 Nov 2003 16:48:08 +: > Le mer 05/11/2003 à 14:50, Stew Benedict a écrit : >> OK folks. FHS 2.3 is currently stuggling with a couple of controversial >> proposals. They would like Mandrake's opinion, as part of what FHS >> tries to do is formalize current convention. United Linux based distros >> use these currently. My take is Red Hat is against them. I'm not sure >> how to reply with a formal Mandrake position, but perhaps posting here >> will give me more of a feel on how the community views these proposals. > >> Addition of /srv: >> >> http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=16 >> >> Addition of /media: >> >> http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=27 > > If only we could have an access to this ... unable to > bugs.freestandards.org ... Well.. I seem to get a bit further than some. I get DNS, but then I get host not responding. Here's what a simple host call says (I use OpenNIC alternative naming system servers as my primary DNS, which might be why I get that far..): bugs.freestandards.org is an alias for base3.freestandards.org. base3.freestandards.org has address 207.235.77.149 The rDNS entry checks out from here as well MTR traces to it OK, altho it shows 10% packet loss (1 out of 10 packets sent lost) on the last hop (base3 as above). TraceTCP (TCPTraceroute) gets there too, but shows port 80 on the target machine is closed, so it appears the machine is up, but the web server is down. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Re: What happened to am-utils?
John Allen posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 03 Nov 2003 18:06:02 +: > On Friday 31 October 2003 5:42 pm, Luca Berra wrote: >> >> btw, is there a way of preventing dynamic to show on an icon on the >> desktop for every automounted directory? >> >> > Eight click desktop, select Configure Desktop, Behaviour, unckeck > "Display devices on desktop" Eight-click?? That's a new one on me!(The triple-dual-right-left click to activate the mouse-commands in gpm was enough for me..) -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Re: Konqueror bug: Internal Server Error on bug page
Jan Ciger posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 03 Nov 2003 01:43:04 +0100: >> No amount of reloading, including shift key, using either Konqueror or >> Mozilla produces any other result. >> >> Also tried from a machine connected via a different ISP in case it was a >> stubborn cacheing issue, but still the same result. >> > I tried to click "vote for this bug" myself, but I have got the same error. It > seems that the bugzilla voting is broken :-(( It eventually took it for me.. The frustrating thing here (but possibly why it eventually took it for me) is that every time I have to do something that requires a user ID, I have to login. So, I clicked the link to view the bug, clicked login, (opened up my file of username/password combos, verified my username and copied my pass to the clipboard,) entered my info and logged in, entered the bug number in the search box and clicked search, found the vote for this bug link and clicked it, entered my login info AGAIN and clicked, got the vote summary page and made the appropriate change, clicked submit, entered my login info AGAIN and submitted, got the error, backed up, entered my login info yet AGAIN!!! and submitted, THIS time it worked, displaying the vote summary with the vote for the new bug shown. The problem, I'm edu-guessing, is some interaction between my normally no-cookies (Konqueror) browser option, tho I have it set to take them from qa for bug reporting purposes, privoxy, which I have set to change cookies to session cookies, but that should only mean I have to log in once each session, NOT once per action as it seems I have to do, and the qa/bugzilla software/site. I have the same problem with the gnome bugzilla (which I use for reporting PAN bugs since I run its betas) as well, and had it b4 I started using privoxy, so it would seem to be a bugzilla/konqueror interaction problem. Cookies work fine at other sites, like my bank, for instance, supporting the bugzilla/konqueror interaction theory. It may be something to do with domain globalization issues re the cookie, with Konqueror rejecting requests for it from the global domain when it was the specific qa domain that set the cookie, or requests from the specific domain when it was set by the global, or some such, is my best guess. Whatever.. it's definitely frustrating.. but I WAS eventually able to vote on the bug, and others seem not to be able to, so perhaps it isn't ALL bad.. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Re: Mandrake uses Photoshop... What a pity!
James Sparenberg posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 01 Nov 2003 20:04:39 -0800: > One must not forget the ill fated M$ Reader conversion tool (Converit > Liturature) which used the C from Convert and the first 3 letters of > liturature. Great product... lousy name. Yes.. I'd read about but forgotten that one, or I would have mentioned it. =;^) That's strong enough it makes me uncomfortable, I must admit, but it makes my point exactly. Hey, no reason to (well, I won't finish that, as I just realized the double meaning in this context, but..), but we ARE talking about a REAL application with a REAL name, CLit, are we not? (OK, how many spam and censorware filters will filter this out, now? ) -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Re: Mandrake uses Photoshop... What a pity!
Rob posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 01 Nov 2003 15:37:52 -0500: > I suppose you wouldn't worry about legal liability for programs called > "New Instant GNOME Graphic Enhancer/Repository" or "KDE Interactive Kernel > Extender" either? I wouldn't worry about legal liability, no, but then that's probably one reason I'm a computer hobbyist, not professional. OTOH, at least the N one is offensive enough I seriously doubt it would gain enough critical acceptance to get much of anywhere as an open source application. (Sorry, but I hadn't even been exposed to the "K" term until I read a mention of it on a list such as this some months ago.. so can't accurately gauge its offensiveness rating -- "honky", "red-neck", and "white trailer-park trash" are POTENTIALLY as equally offensive, but don't have the bite, because those to whom it may apply have apparently simply not taken the extreme offense to it of some other groups to their labels. IMO, that makes sense, as there's really no real reason to take that extreme offense to ANY of them, N word included, but some people do..) If it doesn't gain at least a minimum level of acceptance within the open source world, it's simply not going to have the support necessary to become a major enough application to cause any real problem, as if it's an important niche, some other application will fill any hole it might leave. BTW, if there's any question, I've been marking "other" and claiming "human" on any forms with the race question for some time. I certainly did so for the 2K census. The majority of my close ancestory has been German/English, but IMO, that has about as much to do with my "race" as does "brown-haired", or "hazel-eyed". I simply belong to the HUMAN race, or perhaps more precisely the "Milky-Way-Sol-Earth-Human race". (Maybe I should start putting THAT down on the forms? BTW, wasn't there some movement to make Klingon an official race in the UK, if enough folks claimed it on their census forms? I guess it wasn't official, but what was the final stat on how many folks DID so?) -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Is rpm2cpio usable?
Luca Berra posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 01 Nov 2003 11:07:57 +0100: > On Sat, Nov 01, 2003 at 12:48:37AM -0800, Quel Qun wrote: >>Hi, >> >>I can't seem to get it to work. Example given, >> >>rpm2cpio libMesaGLU1-devel-5.0.1-5mdk.i586.rpm | cpio -ivd >>usr/X11R6/lib/libGL.la >> >>does not create any file locally. > > files in rpm have "./" prefix > please use > rpm2cpio foo.rpm | cpio -tv > to look at contents of archive before crying .. Or try loading the rpm from within mc. Midnight Commander will load the rpm as a virtual file system, displaying the contents, if you enter it as you would an ordinary directory. You can then copy stuff out of it to the dir in the other pane. (I really like mc, It makes my life as my own sysadmin, particularly on a cooker system, SO much easier! =:^) -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Konqueror bug
Jan Ciger posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 25 Oct 2003 19:19:40 +0200: > Anybody else is seeing this ? > > Upon opening a bookmark from Konqueror (http://www.cnn.com/ in this case, > but it happened with other addresses too), I am getting this message : > > "There appears to be a configuration error. You have associated Konqueror > with text/html, but it can't handle this file type." > > When I restart Konqueror, it goes away only to appear again after some > time. > > It is extremely annoying, to say at least :-( I took a break from Cooker and am just getting back to the list, so I can't say I'm updated, but yes, I'm seeing the same, at times. Konqueror will only want to do local file browsing, not work as a web browser. (I don't have anything else besides my router on my LAN, so can't say whether it does smb: or other LAN urls..) $ rpm -q kdebase-common kdebase-common-3.1.3-79mdk -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Mandrake uses Photoshop... What a pity!
Brad Felmey posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 22 Oct 2003 13:06:49 -0500: > On Wed, 2003-10-22 at 10:14, Mike wrote: > >> 1) The many-windows gui design - less said about that the better, esp >> when you have a large image that takes up the whole screen, you have to >> window switch just to change a tool! > > Always on top works well for me. That's always one option.. I seldom need it tho, as I run three monitors.. and no, that's not all that big a deal any more when brand new 17 inch monitors are under a hundred, as are 19s with rebate, on occasion, a $99 (back then, now cheaper..) dual monitor out AGP card, and my old 4M PCI card off my old cards heap. Get the monitor used and add a discount PCI card if you have to purchase it, and it will STILL come in well under $100 to add a second 17" monitor to what you already have, often more like under $50. (US prices and measurements) At that price, I don't know why at least a second monitor isn't almost standard, now days.. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Mandrake uses Photoshop... What a pity!
Rob posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 22 Oct 2003 13:35:22 -0400: > On Wednesday 22 October 2003 12:31, Thierry Vignaud wrote: >> > less hostile interface but also because the two most common >> > cultural references to the word "gimp" in the US (and maybe >> > other English speaking countries) are very, very negative >> uh? >> what're the offenses ? > > The most common use of the word "gimp", sadly, is as a rude > expletive used to refer to a disabled person. It's illegal in > the US to discriminate against disabled people on the job, and > one easy way to end up in court is to use the word "gimp" > carelessly, especially in a large company. It's not as > troublesome as the "n word" but more troublesome than, say, > calling a French person a frog. [] > > I assume the program's name was meant to be something like "imp > with a g at the beginning" but that just sort of demonstrates > the problem with naming things "geverything" and "keverything". I'd guess you assume wrong. If I don't miss my guess, "The Gimp", was a DELIBERATE play on the above meaning, in the same "finger to the man" anti-corporate poking-fun-at-society deliberate way the Linux community has such applications as "Scrotum" (don't recall whether the app is with a g or a c, as it's not one I use, but I do recall seeing the changes announcements for it on the cooker changes list), "BitchX", and "Pimp-Ass Newsreader" (now simply known as "PAN", without the expansion, as the expanded version is apparently to un-PC for the new Gnome/GTK family of applications). The implication, and I immediately grasped this even back on MSWormOS when I was researching switching to Linux, was of course that "The GIMP" was no cripple! Or, early on, it would have been that, well, it may have crippled functionality now, but just wait until we get finished developing it! As Linux grows up and is adopted by the corporate world, somehow, these things seem rather embarrassing, to some, and they'd rather not use the names in question, either changing them, using the acronym, or switching to other alternative programs. IMO, that's not right. Yes, it may be what some would refer to as a "youthful indiscretion", but it's part of our history, and we should not only be proud of it, but continue to embrace it as long as it serves the purpose. IMO, killing that element of Linux entirely would imply crushing the software libre spirity, and will only make Linux into another MSWormOS, GPL or no GPL. If that's what we are to do, why bother switching from MSWormOS in the FIRST place? .. OTOH, I do live and work in the same US as many others here do, under the same anti-discrimination laws..I'm sensitive to the various PC (politically correct) restrictions on speech and behavior we all have to mind at work. However, sensitivity over calling "The Gimp" by its correct name is IMO as misplaced as the local controversy here in Arizona over calling "Squaw Peak" by its right name, just because some folks say "squaw" comes from an Indian word for "whore", a linguistic theory which is itself disputed. What next, erasing all references to "Navajo", because it allegedly comes from a Hopi term meaning "horse thief"? Where will it end? When we have to refer to everything as "this" and "that", because every noun we formerly used is no verboten? (We couldn't even use "X", and "Y", because of the discriminative connotations re X and Y chromosomes, and therefore male and female, sexual discrimination!) Here, I'll continue to use my "Pimp-Ass Newsreader", and my "NOT so crippled Gimp"! -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: 9.2 cannot produce a floppy boot disk.
Guillaume Cottenceau posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 22 Oct 2003 14:25:34 +0200: > John Allen <[EMAIL PROTECTED]> writes: > >> > Not so. I periodically tested the cooker tree for the ability to >> > create a good install and a running Mandrake. >> >> Try this script; it creates a 1680k formatted floppy. > > If we want to go with larger floppies with 1.44 MBytes drives, we > need serious testing. I'm afraid this brings lots of hardware > problems (and floppies already have much hardware problems). > > Not talking about frying the floppy drive, a-la LG? :) I'm not sure how large one can go w/o trouble, but Microsoft even used specially formatted extra high capacity floppies for some of its stuff back ~ MSDOS 6.x, and probably with the '95 available by special order on floppy. I think they were at least 1680k, tho.. Also, I used to have a custom formatter I got off of one of those old shareware/freeware utility CDs, that allowed up to (theoretically) 1.9M.. IIRC. The readme.txt that came with it said try it on your drive until you get the max possible. It said most wouldn't do as high as the formatter could go, but could do far better than the 1.44 default. It also said if you heard extra clicking you were pushing it to hard, abort, and back off a bit, or risk damaging the drive. I believe 1680k should be about the common top, however. Pushing it, but most drives should do it without damage. I'm sure a hardware guru from that era should know more about it than that, and I'd definitely recommend confirming it either with one of them or a current drive manufacturer, but I BELIEVE 1680k should be reasonably doable without harm. One might also be able to get some info from someone either still having or remembering the details of the old MS format.. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Re: 9.2 disasters list (continuing)
Ron Stodden posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 20 Oct 2003 12:23:18 +1000: > Duncan wrote: > >> If you don't use core files for debugging, it's probably wise to turn >> them off. See the ulimit builtin from BASH, and the entry in >> /etc/profile. Note that the default is no core files, and the profile >> entry turns them on for root, with a limit of 1,000,000x1024 bytes!! >> With a 5G /, you are lucky it was only 7.8M, instead of closer to the >> nearly a gig limit! > > Thanks. I commented it out in /etc/profile, viz: > > # Users generally won't see annoyng core files # [ "$UID" = "0" ] && > ulimit -S -c 100 > /dev/null 2>&1 > > and look forward to no further problem (fingers crossed :-) ). > > I cannot decode your mention of bash´s ulimit command into some > desirable action (no man info found). (I took a little break from the list, for awhile, and am just catching up again, thus this reply to a nearly two-week old post..) That's it. As for info on ulimit, as I said, it's a bash built-in command, so it will be under the bash man page, not its own. The bash man page is rather more like a man BOOK, or even a man ENCYCLOPEDIA , it's so long, but using the Mdk default less as the man pager, "/" puts man (or less, actually) into "find" mode, so you can use "/ulimit" and then hit return to search for it once the bash manpage is loaded. Or.. at least with the manpage version as I have it here.. ulimit is covered starting at line 4305, it looks like. More in general.. for those not already very familiar with bash and bash/sh scripting, that entire man page contains some VERY useful information.. Well worth browsing thru when you have some time. Or.. for a good all around Linux reference book, try O'Reilly's "The Arabian", aka "Linux in a Nutshell". The main part of the book consists of a quick-reference of most of the common Linux commands used in console mode. However, it has additional chapters on some of the more complicated stuff, including one on bash, one on package managers (rpm and the debian package manager), another as an intro to regexps, another on LILO, etc. The BASH, regexp, and package manager sections, I use enough to have color coded the edge of the pages so I can turn right to those sections when needed. (The other book I found equally helpful when I decided to get serious about Linux, but one that's more of an introduction or beginner tour, so not used so much as a reference work now that I'm familiar with Linux, was again an O'Reilly book, "The Rearing Horse", aka "Running Linux". Together these books advanced me AT LEAST a quarter's worth of full time learning ahead of where I'd have been learning Linux without them. They cost me a total of about $70 (US) at Fry's Electronics, but they came well recommended, and I count that as one of the best purchases I've ever made.) -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: 9.2 disasters list (continuing)
Ron Stodden posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 19 Oct 2003 00:27:17 +1000: > -rw---1 root root 7827456 Oct 18 23:35 core.5465 If you don't use core files for debugging, it's probably wise to turn them off. See the ulimit builtin from BASH, and the entry in /etc/profile. Note that the default is no core files, and the profile entry turns them on for root, with a limit of 1,000,000x1024 bytes!! With a 5G /, you are lucky it was only 7.8M, instead of closer to the nearly a gig limit! Here, I commented out that line, so root doesn't create core files either, as all they'd do is waste space. If I happen to be troubleshooting a bug where I've been asked to retain them, I can always change that then. Meanwhile, I don't have to worry about the space they might take. .. Perhaps this default should be changed. People that can use core files should know how to change the setting. However, for the average MSWormOS switcher, the current settings could be an invitation to disaster, particularly as this is set for root, meaning it can eat into the emergency system recovery reserve. I'd say let them remain off by default, but at least limit their size to something more reasonable, say 100M or less! -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Re: 9.2 disasters list (continuing)
Brook Humphrey posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 19 Oct 2003 05:27:08 -0700: > AS for mc every sysadmin I show it to uses it. It is way more useful in > the real world than emacs. Especially for system recovery. It is kind of > like an all in one tool for when things go bad. I even use it allot > under normal conditions to install rpm's. Especially when the system is > hosed and there is not other way to install them. I agree! I even fire up mc in konsole under KDE fairly frequently. It sure beats Konqueror for speed on a dir with lots of files that Konqueror want to load the icons for! I even redid its menu, adding a couple custom urpmi and rpm entries. Now, when urpmi refuses to install the big lot of stuff selected with an --auto-select, I load mc and point it to the rpms cache, and try them one by one installing everything that WILL install, then track down the problems with the remaining ones and see whether I can safely force them or not. It's definitely easier than typing it all into the command line a package at a time, when there's a couple hundred to try. (Of course, a REAL sysadmin would create a script to try each one individually, but automatically. I haven't gotten that far yet. =:^) -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: [Mandrake 10] Ideas for RpmDrake [long]
Robert L Martin posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 13 Oct 2003 22:15:28 -0400: > 3 a trio of SUID ROOT scripts to : a shutdown the system b reboot > Xwindows only (user switch) c do a full system reboot || note on systems > with a Real Live BOFH admin this trio would be yanked || Perhaps this in low security mode, but not above 2, anyway. I don't WANT any rouge program being able to reboot the entire machine w/o having to know the superuser (or at least SOME) password. That's something we have that is and should remain better than Gates as it is, IMO. OTOH, this is yet another good reason to get a sensible sudo setup and some sort of GUI compatible with it.. Allowing a user access to these functions, but with password, IS a good idea, IMO. From there, the local admin (be that a real admin or not) can change it to no password needed directly, or by changing the security level, as desired, but that should NOT be the default, IMO. Linux is superior in this area by the definition of most experienced users in part BECAUSE it emphasizes security over ease of use, and that should not change. Otherwise, why not just run Lindows style, only one physical user account by default, ROOT! -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Re: setting most recently used menu
Simon Oosthoek posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 11 Oct 2003 22:48:08 +0200: > On Sat, Oct 11, 2003 at 05:58:02AM -0700, Duncan wrote: >> Mandrake's menu system is based on the Debian menu package. KDE packages >> are adapted to use the Debian global menu system, which then recreates the >> KDE menu, including non-KDE Mandrake applications in it that wouldn't be >> included in the official "non-distrib-ified" KDE product. > > Do you know a good pointer to documentation for this intertwined feature? > Menu's have been a mystery to me for quite a while, I'd like to know how it > actually works... /usr/share/doc/menu-X (currently X=2.1.5) Basically, the idea is to create a global system menuing system that can be adapted (thru the use of scripts for each window manager or environment) to all the various windowing systems, such that a menu entry must be added only once for each new installed item, and each window manager will automatically pick it up and add it to its own menu. The system allows for wm/environment specific attributes for each one, such as the various custom stuff entered in each KDE *.desktop file, and for entries specific entries only to be used with one wm/environment. KDE itself, as mentioned, uses *.desktop entries in a subdir system very similar to the MSWormOS start menu idea, where each menu entry is a separate file in the file system. Unlike the MSWormOS start menu, however, the menu entries track file type associations, the app that launches when you left click (or doubleclick depending on your KDE options), and additional apps available to "open with". This is what managing the file type in KDE changes -- the priority number assigned to this *.desktop entry for opening that file type. and the various entries that are associated with it that can open it. Unfortunately, changing those attributes doesn't make the same changes in the Gnome menu (well, that's good in some ways, as you might not WANT it to open with say Konqueror when in Gnome, but ..) and in any case, as soon as you upgrade, which happens pretty frequently when one is running Cooker, the changes are often erased. Debian came up with the menu package, which Mandrake adopted, which makes global changes possible. Edit the menu once, globally, and changes are applied to all window managers as specified in the *.mnu files you (or whatever graphical front end such as menudrake you are using) create. As I mentioned, however, using menudrake has its drawbacks. One of them is that most of the custom KDE attributes, for instance, show up in a single **VERY** long at times string, and the window for editing these attributes in menudrake is **VERY** small by comparison, only a few characters, so you get the "keyhole" effect. Another problem with menudrake is that there's no easy way to duplicate entries, if you want a menu entry in two different locations or want to duplicate one in ordered to change it a bit for a second entry. Yet a third problem is that the icon choice in menudrake has no accompanying text box for direct path entry -- one cannot see where the icons are nor enter their own path, all one can do is choose from a limited system set already there. The final problem is that *.mnu files can consist of a single menu entry per file, or be grouped, and menudrake groups **ALL** its changes into a *SINGLE* override file, easy to backup if one knows where it is, but not so easy to hand edit, and not very robust. (Most *.mnu files are only a single menu entry, far easier to maintain and change by hand, and if one gets corrupted, the rest remain fine. Using the documentation found above, however, and looking at a number of existing *.mnu files, I was able to figure out the format, and now make all my changes by hand. A general list of most possible entries for the distrib is stored under /usr/lib/menu/. This includes entries for apps that aren't installed, as well as installed apps, with each *.mnu file including both a package that must be installed to activate it, and an environment (general X, KDE only, Gnome only, etc) under which it is to be viewable, the latter corresponding to the entries in menudrake that are visible only under one environment, not all of them. Thus, installing the package automatically activates the *.mnu file and adds the menu entry for it, while uninstalling it removes it, deactivating the *.mnu file. This is accomplished thru a step in the appropriate rpm script that invokes update-menus, a command that can be invoked by hand, as well. Sysadmins may create override entries to add or change the defaults and put them in /etc/menu/, which is in effect what menudrake does when you customize the menu. Again, the problem with menudrake is that it puts all its customizations in a single hard-to-maintain-by-hand file, while it's generally e
[Cooker] Re: setting most recently used menu
Keld Jørn Simonsen posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 09 Oct 2003 17:40:13 +0200: > On Thu, Oct 09, 2003 at 12:23:51PM +0200, Buchan Milne wrote: >> >> Keld Jørn Simonsen wrote: >> >> > Also I then noticed in the kde control center that there was a looknfeel >> > section with a panel editing posibility, but that did not include >> > editing this item. I find it strange that the kde control module is not >> > available from the kde control center. >> >> It is there, KDE Control Center->LookNFeel->Panels->Menus (tab) > > I cant find it there, I looked all over again. Current cooker. > There is no menus tab under panels (or the one that is there, is only > for setting the background for the menus.) Here, it's under KControl, LookNFeel, Panel, Menus (tab). That's a separate entry from Panels, which as you note, is for setting menu item background only, and has only a single tab. However, at some point in Cooker, there was a complication with the menus that I had to resolve manually. I'm guessing this is where the issue is. Mandrake's menu system is based on the Debian menu package. KDE packages are adapted to use the Debian global menu system, which then recreates the KDE menu, including non-KDE Mandrake applications in it that wouldn't be included in the official "non-distrib-ified" KDE product. KDE as installed here now includes both a "panels" and a "panel" menu entry. However, as in the Mandrake/Debian menu package, both entries are listed with the "panel" name, which obviously creates a conflict with KDE, since it uses separate *.desktop files for each entry, and there can't be two "panel.desktop" files in the same LookNFeel dir. I suspect that one of these entries is for an old version, and that either the current KDE only includes one of them, or has a different name for the other one. However, somewhere in the untold updates I've done to my Cooker KDE packages, the one wasn't renamed or removed as it would be in the current packages, thus, I ended up with duplicate names, which meant when the menu was created during install, the last one to be created overwrote the previous one. Once I realized functionality was missing, and saw from menudrake that there was supposed to be a second menu entry that I was missing, I went to found the appropriate *.mnu entry in /usr/lib/menu and copied it to /etc/menu (where the local sysadmin overrides live), then changed it as appropriate so it wasn't stomping on the other entry, by adding an "s" to the "panel" that was the former KDE file name used. After rebuilding the menus, I had both entries once again, with all the functionality I was used to, and I was once again a happy camper. Note 1: I could have managed the change directly from menudrake, but that I find menudrake a bit limiting and it's single override file solution a bit less than robust, so any changes I make to my menu system I now make manually, to the core *.mnu text files, as appropriate. I only use menudrake for read-only checking the menu, as I did in the example above. Note 2: This Mandrake/Debian menu system solution is why the KDE 3.2 alpha2 packages Laurent put out don't integrate with the standard Mdk menus, having only the KDE original menus, because they haven't been patched for the Mdk solution, yet. Note 3: This missing kcontrol entry is a bug. However, I haven't filed it as such, because I've customized my menus to the point I'm not certain whether it would exist on a normal system or not. IOW, I wasn't certain whether it was my customization at fault, or Mandrake's. Anyway, the functionality is there, but it may be missing from your version (as it was from mine until I fixed it), due to the missing entry, due to the file naming conflict between the two kcontrol applets. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Re: [Mandrake 10] Ideas for RpmDrake [long]
FACORAT Fabrice posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 09 Oct 2003 17:44:16 +: > Le jeu 09/10/2003 à 12:50, Duncan a écrit : >> Svetoslav Slavtchev posted <[EMAIL PROTECTED]>, excerpted >> > it could be in a sub menu "install more software", >> > which uses the menu structure of the main menu, >> > has nice icons, and a good description >> >> I like this idea. Have one entry on the menu that leads to another copy >> of the menu, as suggested. > > beurk ! > In all usability test you will see that you should avoid more than 3 > level in menu. Another sub menu could put 4 level and even 5 level ! > tooo much. > And you will decide which apps to put ? The additional levels would only be activated if someone is attempting to (un)install something. On the regular menu, there'd be one single entry that would then pop up as a submenu the entire menu, with all possible menu entries there, installed and uninstalled. If someone were to wish to change installed programs, then, they'd use this menu entry, which would then become effectively the top level menu for installation. If one still insists on the usability limit of X levels of menu, simple! Just create an app that has only two entries, an exit, and a copy of the normal menu, but with all possible menu entries displayed, installed or uninstalled. >> However, having as one entry a nested copy of the main menu layout, >> with all possible entries on it, for (un)installation, would be >> manageable using the current interface. All it would require would be >> some more text format .mnu files under /usr/lib/menu, and perhaps >> loading a few more icons, tho not many as many of them are used >> multiple times as is. > > 1°/ disk space Hardly an issue. Pretty much everything is already there. The files in question are *.mnu files, comparatively small text files. If block usage is a problem, simply use the menudrake solution and put all entries in a single file. Take a look at /usr/lib/menu, and /etc/menu, for what's currently there. The other thing would be the icons for the menu entries, but as I said, many/most of them are already there as well. There would be very little additional space used. Maybe for one more app/package, that's it. Of course, the screenshots package would be bigger, but that'd be separate and optional. > 2°/ complexity when parsing this Again, it would use the existing solution, so would be no more complex than the existing solution. > 3°/ menu bloat Not a problem. As originally proposed, everything would be under one submenu entry. Don't activate it when you aren't installing/uninstalling. In the modified application proposal above, even that would disappear, as everything would be in the menus as displayed in the install/uninstall app. > 4°/ time/cpu consuming when need to update menu ( as you need to > reparse everything, etc ... ) It's already done when installing packages or whatever. Yes, this would add a bit of additional time, but it would only happen during application install/uninstall, when there's some time taken anyway. >> Item entries on this new menu would call up a tool that would see if it >> was installed already or not. If so, it would offer the user the >> option of uninstalling it. If not, it would offer the user the option >> of installing it. > > this features exist before ( normal click and not right click ) and mdk > remove it as this was too buggy. It uses the same system as currently used, so how could it be to buggy, unless the current system is to buggy? >> Alternatively, packages could be modified to change this menu entry >> upon installation, and change it back upon uninstall. In this way, the >> entry could display say an x if uninstalled, or a plus if installed, >> making it immediately obvious what was installed from the installer >> menu, without having to take a trip back out to the main menu to look >> again, if in doubt. > > How are you going to manage this ? The same way new menu entry additions are already processed, when a new program is installed or uninstalled. Only, instead of one entry being processed, there'd be two, one changing the operational menu as is currently done, the other toggling the install menu entry between install and uninstall, a simply change of two parameters in an otherwise identical entry, most likely, one changing the installed indicator in the title from say "x" to "+" (or the reverse), the other toggling the parameter sent to the installer similarly. IMO, this remains one of the better solutions, because it works with what's already there and tested, requiring only small changes and a different urpmi front-end, to implem
[Cooker] Re: [Mandrake 10] Ideas for RpmDrake [long]
Buchan Milne posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 09 Oct 2003 16:41:52 +0200: > Rob wrote: >> On Thursday 09 October 2003 08:35, Buchan Milne wrote: >> >>>Make the policy that all application screenshots should: >>>- -be of only the application (no desktop) >>>- -not have window decorations >>>- -use MandrakeGalaxy widget theme/style if applicable >>>http://ranger.dnsalias.com/mandrake/screenshots/imgseek2.png >> >> >> I think the lack of window decorations might be a little >> confusing to the kind of users who'd benefit most from >> screenshots. Maybe require the use of the MandrakeGalaxy window >> decorations too? > > But that requires the user to use one of the window managers that has > MandrakeGalaxy decorations ... > > Of course, it would be a bit less effort (since none of the mainstream > screenshot tools has an option to not use the decorations) to include them. IMO, application window only, but submitter's choice of window decorations are fine. Screen shots at the various Linux sites use various decorations, and it doesn't seem to cause any problems. The same goes for color scheme. Any scheme should be allowed. Linux isn't Windows, where there's only one shipped window manager, and even Windows has color schemes. Therefore, it shouldn't be a problem. Anyone confused by it, well, this is Linux, not Windows. One of the benefits of Linux is the amount of customization one can do. In fact, before I moved from MSWormOS myself, that was one of the things that impressed me with Linux -- the huge amount of customization visible in the various screen shots I laid eyes on. In fact, I'm guessing what could actually happen is that users may see decorations they like and club, etc. may need to dedicate a new forum to questions about how to get the effect seen in screenshot X. One interesting possibility would be to collect this information and make it available at an appropriate club or whatever URL, where one could take a look at the screenshots online as well, even if included in the distrib. Thus, we'd have for a description of a shot, say, of kmail, if I took it: KMail, main screen, KDE environment, Custom color scheme, Keramik style, Redmond decorations. This online version would be quite handy for folks wishing to take a look at what was available with Mandrake before switching, as well, and could produce a substantial number of new users! I know I'd like to send a couple folks to visit, as they consider me a computer guru, but are a bit hesitant to take up Linux currently. That might get them interested, then I could let them borrow a "live" CD, then.. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: [Mandrake 10] Ideas for RpmDrake [long]
Svetoslav Slavtchev posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 09 Oct 2003 12:58:46 +0200: >> Le mer 08/10/2003 à 22:58, Keld Jørn Simonsen a écrit : >> >> No please. because : >> 1°/ the menu will be cluttered at first, You'd rather install >> automatically a selection of package you think that will be usefull for >> the user >> 2°/ a user expect that applications in his menu are installed ! If he >> clicks and nothing happen, his first though will be : It's broken. Right >> click and then install ? see point 1 > > 3°/ (hi hi) > it could be in a sub menu "install more software", > which uses the menu structure of the main menu, > has nice icons, and a good description I like this idea. Have one entry on the menu that leads to another copy of the menu, as suggested. Note that menu right-clicking would be a function of the environment used. KDE, the Mdk default, may well (probably will, as the current menu is comparable to the Win95 menu at this point, and folks used to W98+ functionality with dynamic right-clickable reorganizeable menus would find it useful) include right click functionality of their own at some point. I don't believe patching Mdk's KDE to include install, therefore, is a very good idea. However, having as one entry a nested copy of the main menu layout, with all possible entries on it, for (un)installation, would be manageable using the current interface. All it would require would be some more text format .mnu files under /usr/lib/menu, and perhaps loading a few more icons, tho not many as many of them are used multiple times as is. Item entries on this new menu would call up a tool that would see if it was installed already or not. If so, it would offer the user the option of uninstalling it. If not, it would offer the user the option of installing it. Alternatively, packages could be modified to change this menu entry upon installation, and change it back upon uninstall. In this way, the entry could display say an x if uninstalled, or a plus if installed, making it immediately obvious what was installed from the installer menu, without having to take a trip back out to the main menu to look again, if in doubt. The core Mdk installation would include a mandrake-installer-menu package, with the installer/uninstaller app, and possibly the additional menu layout (which would otherwise be packaged and installed with the standard menu package). A separate package, say mandrake-installer-menu-screenshots, could be made optional. I haven't actually run a full distrib install since 8.1 (as I urpmi upgrade instead), but if a fairly standard normal vs. custom/minimal install option is used, normal would include the screenshots package by default, but custom/minimal would not. As for space, yes, the screenshots package WOULD take a non-trivial amount of additional space, but if done right, I believe it would be well worth the cost in terms of trading out another package to include it. I'd suggest putting screenshots on disk 2 (or even 3), but the installer menu on disk one, if possible, or in place of rpmdrake or whatever, whichever disk that's on. (Rpmdrake and anything else it replaced could then be put on disk 3, or later (left off the disks, as many apps, on the mirrors and in packaged sets, if the d/l edition remains @ 3 disks), rather than removed entirely, if so desired.) As well, low rez or highly compressed jpgs could be used, helping to control space use. Again, yes, this WOULD mean a trade-off, but I expect newbies would more than appreciate the additional ease of use, making it well worth it. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: [Mandrake 10] Ideas for RpmDrake [long]
Robert L martin posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 08 Oct 2003 22:30:01 -0400: > what i would like to see is a way to right click on a loose rpm and see > whats inside (isn't there someway to do this with the rpm cli??) In X, kPackage can do this. kPackage is now a separate install as kdeadmin-kpackage, I believe. In console mode, mc of course does this (well, sort of, not exactly right click, but..) and all sorts of other stuff, using a curses interface. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: menus/menudrake
J.P. Pasnak posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 04 Oct 2003 15:54:00 -0600: > > Has anyone else experienced problems with menus under Cooker? I recently > upgraded a box to Cooker, and the only things in the menu are 'Logout/Lock > Screen/Recent Documents/What to do?'. The 'What to do?' contains the > 'helpful' links to applications, but the normal Mandrake entries do not > show up (Applications/Multimedia/Networking/etc) > > Normally, if I run into this, a quick load of menudrake and a save resets > everything (or an 'update-menus'). This time, no luck.If I use > menudrake to switch to the 'standard' menu (or change > ~/.menu/enable_mdk_customization to ~/.menu/disable_mdk_customization), > the 'standard' menu appears, but I've found no way to get the Mandrake > menus back. > > Any tips/hints/suggestions/links welcome. There's a couple threads on this already. I haven't come across it, probably because I don't have the window manager in question installed, but several report it's an unparsable menu file. As root, from a console or console window, run update-menus -v (for verbose) to see where it chokes, and manually edit the file (as outlined in the menu docs) to correct the issue. As mentioned, it was reported to be related to one of the window managers, but IDR which one (not gnome/kde/icewm or I would have remembered and probably run into the problem myself). -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Please excuse my ignorance.........
Steve Larabee posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 02 Oct 2003 11:07:44 -0400: > I am brand new to the "Cooker" scene and am having trouble finding the > most effective way (not to mention reliable FTP site) to keep updated. > > Please read the list guidelines on the Mdk site then, and turn of your HTML posts. HTML is for spammers and crackers, and AOLers that can't read such guidelines or be bothered to check their posting configs to turn it off. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: errata 9.2
John Allen posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 04 Oct 2003 12:06:07 +0100: > > HTML in mail is for crackers and spammers, and of course the AOLers that don't know better and/or can't read the list guidelines or be bothered to check their posting config. What is it doing here? -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
cooker@linux-mandrake.com
Greg Meyer posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 25 Sep 2003 18:22:31 -0400: > On Thursday 25 September 2003 12:09 am, Han Boetes wrote: >> Greg Meyer <[EMAIL PROTECTED]> wrote: >> > Fresh install, log into fluxbox, no [EMAIL PROTECTED] terminal. >> >> Can you debug that? >> > Yeah. I can't start a terminal because there is no menu entry for a > terminal. Since I can't start a terminal to get a CLI, I can't start a > terminal from the CLI. > > No menu entry for rxvt and no menu entry in fluxbox menus for konsole. Does fluxbox not have a "run dialog" then? Even without a menu entry for a terminal, a run dialog should be usable to start one -- unless of course you don't know the actual command name, but anyone that actually misses a terminal should be able to figure /that/ out. Of course, no run dialog and.. Or.. start up a file browser and launch it by clicking on the file there.. Or.. start up Konqueror and use the launch terminal command there, or activate its builtin terminal pane, or use its shell command function (basically a run dialog). Of course, if the konsole entry is missing, kdebase-konsole may not be installed, and I'm not sure if those entries will work. Still, the shell command function should. Someone mentioned mcc/drakconf still has a shell function.. Of course, that does require root.. I'm sure there are probably many other apps that can launch either a shell directly, or a run dialog from which one can be launched. As I was just reading in the sudo documentation the other day, it can be difficult to restrict a user who want to launch a shell from doing so, unless you restrict him from running all the various apps that have that functionality as well. Oh.. another one.. menudrake.. then create your menu entry, and run it.. assuming of course that IT'S in the menu (and that fluxbox uses the Mdk menu system, but I'd guess it does). -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Post 9.2 urpmi security suggestion/question
History.. A couple years ago I left MSWormOS behind, and jumped to Mandrake Linux. Back on Lose98, everything effectively ran as root. Since switching, I've been a good boy and learned NOT to run stuff as root, except where necessary. With that in mind, I've become increasingly uncomfortable running urpmi, downloads and all, from root. I don't surf the web as root, and for good reason, I expect most will agree. I understand the need for root for the installation steps, but why must the files be downloaded as root? That seems like far less than a secure solution, from here. Having been on this list a bit over a full release cycle now, I've waited for this to come up, as I was SURE I was missing something obvious and if I just kept quite someone else would raise the issue and I'd be able to learn.. However, that hasn't happened, and at the expense of looking foolish for overlooking the obvious, I'm now raising the issue, as I'm becoming increasingly uncomfortable with the current situation. Looking over the current situation, with urpmi requiring root, while some other "safer" functions such as urpmq are available for use as a user, and with what I've managed to understand from other packages and what runs as root and what doesn't in the rest of the distrib, I've come up with a proposed solution, that of running only the install functions as root, with the rest of the procedure, particularly the downloads, handled as an ordinary user. 1) Split urpmi into two different steps. A normal user privileged step would query the rpmdb for current versions, figure out the updates available, and download them. A second step requiring root would then do the actual installs. 2) Create an urpmi user account to execute the first step and own the local hdlists, config files, and caches. This would keep update functionality separate and prevent possible security issues with basically everything else the (human) user might be running having access to the updates in process, if this step were to be handled by a normal user account operating non-core and possibly not completely trusted applications. 3) Set up the rest of the urpm* family (.update, .add/remove-media, etc.) to use the same user. 4) Set up the main urpmi script such that when invoked as it is now (must be root) it runs urpmi-user portion first, waiting for it to complete, then runs the root-user portion. Discussion: Some may argue that this won't provide any more security anyway, as any interference could just be done to the downloaded packages instead. While this might be true as far as the package data itself goes, it doesn't see the larger possibilities for mischief. 1) If there exists a vuln in curl or wget, it might be possible to trigger arbitrary execution of code with a specially designed packet inserted into the d/l stream. It's possible a third party could insert this, so it wouldn't have to be the ideally trustworthy mirror server. Should this occur, it'd be far better for said execution to run as an unprivileged user than as root itself. 2) Packages are now for the most part signed, such that direct interference with them would be detectable. Thus, that's less possible, as would be interference with them from an execution vuln in ordered to get more privileges during the install phase. 3) That has the effect of limiting security issues to (1), arbitrary code execution during the d/l, which as I said, is far better limited to a non-privileged user than running as unrestricted root. I still have a difficult time believing I'm the first one to see this, which means I'm probably missing something obvious. However, in contemplating this issue, I haven't stumbled upon it in several months, so either this is the better security solution I believe it to be (and is as practical to implement as I suppose it should be), or it's going to take someone else to explain to me what I am missing.In either case, here's the suggestion, for what it's worth. It's pretty much the beginning of a new development cycle, so probably as good a time as it gets, to post this. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: 9.2 ISOs has been sent
Adam Williamson posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 24 Sep 2003 23:45:56 +0100: > On Wed, 2003-09-24 at 16:37, Serge Pluess wrote: > >> I agree that this is a good approach to encourage people to join, but >> for the comment of the boxed-set, that just seems to be more-or-less a >> joke. >> 9.0 and 9.1 boxes never hit the shelves here at the main stores such as >> Fry's Electronic, CompUSA or BestBuy. One day one lonely box of 8.2 was >> sitting at Fry's next to lots and lots of boxes of Redhat 9, Suse 8.2, >> and current versions of Lycoris, Lindows, FreeBSD and NetBSD. > > not everyone lives in America. not everyone buys boxes from stores. No.. but for the rats jumping the MSWormOS ship, here in the US, having the boxed version available is important if you want their first Linux experience to be Mandrake, rather than one that IS available, and on the shelf. How do I know? I was in that position not SO many years ago, myself. My first Linux experiment was Mandrake 5.0, IIRC, the Macmillan (sp?) version. I tried it but didn't do much with it after the install. My second one was Mdk 6.1 IIRC (whatever one it was that first had the Athlon patches). Again, I didn't do a whole lot with it, but having done both of those, and having decided to get serious so having asked for recommendations and having read the Rearing Horse (OReilly's Running Linux) I was ready to try 8.1 d/l edition straight off the mirrors, as it wasn't available in stores yet, unfortunately. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: [Bug 5859] [initscripts] Improve startup speed (solution in this report)
Bellegarde Cedric posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 21 Sep 2003 03:26:16 +0200: > It don't works for me :-/ > Can you make a tar of your /etc/rc.d dir? > It will be easiest to see how it work, i don't understand how can you > call /etc/init.d/halt as *reboot ? Simply create a link to it, and call the link "reboot" (or in this case s99reboot or whatever). The system takes care of the rest. The same type of idea is often used with other programs, If U R a vi/vim fan, for instance, you may use the read-only version "view". On a Mdk system, view is the beginning of a symlink chain similar to what follows (I have ll as aliased to ls -l): $ which view ... /bin/view $ ll /bin/view ... /bin/view -> /etc/alternatives/view* $ ll /etc/alternatives/view ... /etc/alternatives/view -> /bin/vi* $ ll /bin/vi ... /bin/vi -> /etc/alternatives/vi* $ ll /etc/alternatives/vi ... /etc/alternatives/vi -> /usr/bin/vim-enhanced* $ ll /usr/bin/vim-enhanced ... /usr/bin/vim-enhanced* The system will invoke vim-enhanced as "view", which the binary detects, and loads the file read-only. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: Serial ATA support
Brook Humphrey posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 15 Sep 2003 07:01:18 -0700: > what about high point they clearly state that they support linux mandrake > right on their literature. well and redhat and suse. Didn't I read their RAID drivers anyway are sort of like NVidia's drivers -- available but proprietary? If that's accurate (and it may not be if I'm recalling inaccurately or my source was incorrect), they'll likely be doing the same thing with Serial ATA drivers.. I made that mistake once with an NVidia video card, b4 I switched to Linux, as I was thinking about doing so and knew enough to ensure Linux drivers were available for any hardware I purchased, but unfortunately didn't realize there WAS such a thing as closed source hardware drivers, at the time. That's one mistake I hope to avoid, next time, and certainly don't want to expand to any other components! (I happen to be interested in the this thread as well, tho I will probably wait a bit for my upgrade, and hope to do a Socket 940 dual Opteron/Athlon-64 when I upgrade, as well as serial ATA, and I still have to look into PCI-Express which I've just seen hints of but don't know what it's all about yet.. if I can hold off on the upgrade long enough to get what I really want.) -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: posting from gmane?
Luca Berra posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 15 Sep 2003 00:04:58 +0200: > Duncan wrote: >> I am now subscribed to this list as a newsgroup thru gmane, and wish to >> stop getting it in my mail box, but still be able to post to it. >> However, if a poster isn't a member, mail must be confirmed. >> Unfortunately, SYMPA-Mdk doesn't mention a subscribed but no delivery >> setting for this list as many have. >> >> Does anyone else post thru them? How do you manage it? >> > read the headers of mail :) > > mailto:[EMAIL PROTECTED] Thanks. I read my welcome message, and checked the list web page, finding instructions for an info message, so requested that and read it, but none of them had the nomail setting listed, and I didn't check headers themselves so didn't see the help command listed there. I thought /sure/ it should have such a setting, but I could find no instructions for how to invoke it, so I asked.. and got them. =:^) Thanks again! .. Now if only PAN filtered/scored on anything but overview available headers.. It doesn't (yet), and I just realized a few hours ago that means I can't filter out HTML directly as I did w/ KMail. I can still plonk the bozos that use it, tho! -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] Re: mozilla-devel not included with RC2
Frederic Crozat posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 15 Sep 2003 14:08:09 +0200: > On Mon, 15 Sep 2003 05:05:01 -0700, Ric Johnson wrote: > > >> --- Götz Waschk <[EMAIL PROTECTED]> wrote: >>> Am Montag, 15. September 2003, 04:28:36 Uhr MET, schrieb Ric Johnson: >>> > Why? >>> Space constrains on the CDs. >> >> Are you sure about that? That does not make any sense to me considering >> the large number of non-essiential programs that could have been removed >> and that mozilla is the default MDK web browser since they dropped >> Netscape. > > Mozilla-devel is useless for most people, unless you want to build apps > which uses gecko.. .. And one would /think/ that someone with that sort of interest would pretty quickly discover the online media sources, as well. At least, a developer or even a user that would need to install it to manage his own compiling or rpm rebuilding would be far more likely to already know and be able to manage an online d/l source than joe user with his "non-essential" screen savers and other toys. As well, a Mozilla developer or referencing package compiler will far more likely have a decent speed net connection, than ordinary joe user with his dialup modem, by self-selection on the types of devel package he's interested in. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
[Cooker] posting from gmane?
I am now subscribed to this list as a newsgroup thru gmane, and wish to stop getting it in my mail box, but still be able to post to it. However, if a poster isn't a member, mail must be confirmed. Unfortunately, SYMPA-Mdk doesn't mention a subscribed but no delivery setting for this list as many have. Does anyone else post thru them? How do you manage it? -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
Re: [Cooker] Undefined Symbol in latest libfontconfig1 crashes KDEINIT
On Fri 12 Sep 2003 17:58, Buchan Milne posted as excerpted below: > On Sat, 13 Sep 2003, Bill Greenwood wrote: > > Undefined Symbol in latest libfontconfig1 (2.2.1-6) crashes KDEINIT > > > > Tried submitting this to Bugzilla, but would not take it, > > so here it is: > > > > Trying to start KDE with the latest packages, XFree starts and > > a dialog box pops up on the top left corner stating: > > Could not start kdeinit > > > > After pressing Okay, crashes back to console. > > > > Three errors show, and they are all related to: libfonfig.so.1 > > Stating in part: Undefined Symbol: FT_Get_BDF_Property > > > > Recently upgraded system from pre 9.1. > > It seems no-one else is seeing this. Can you report the versions of all > the relevant library packages? At least libxfree86 and libfreetype2, > and I guess libqt3 too. As I just mentioned on the other copy of this.. (grr.. ) I'm seeing either this or something similar. (I have an rpmq shell script that runs rpm -q, thus the command as below.) $ rpmq -a|grep libfreetype libfreetype6-2.1.4-6plf libfreetype6-devel-2.1.4-6plf $ rpmq -a|grep libxfree86 libxfree86-4.3-23mdk libxfree86-devel-4.3-23mdk $ rpmq -a|grep libqt3 libqt3-3.1.2-14mdk libqt3-devel-3.1.2-14mdk Note that I'm also running the NVidia proprietary drivers as well as S3/Virge XFree drivers, the former to allow connecting two monitors to my GForce2 AGP card, the latter for a PCI card connected to a third monitor, using Xinerama. No errors in XFree86.log, X comes up but KDE never starts and eventually reports "giving up" to the console. I hadn't run the dm and graphically logged in in ages, as I prefer starting KDE directly from a console, but it does seem to work now, which is how I have KDE and KMail running to get and reply to this thread. At first I thought it was the NVidia drivers not liking the latest XFree, and refusing to start KDE tho X would start. I've had that happen b4 and had to recompile the drivers to fix it. However, since it works from the dm, that now seems less likely. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
[Cooker] Re: [Contrib-Rpm] bugzilla-2.16.3-5mdk
On Fri 12 Sep 2003 07:16, Oden Eriksson posted as excerpted below: > [Contrib-RPM] > > -=-=-=- > Name: bugzilla Relocations: (not relocateable) > Version : 2.16.3Vendor: MandrakeSoft > Description : > Bugzilla is the bug tracking system developed by mozilla.org. > Mozilla.org is a group within Netscape that acts as a > clearinghouse for Netscape source code. Some modifications have > been made for use with Mandrake Linux. This description needs updated, since it's now "the late Netscape"... I'd guess the reference to NS could probably be entirely removed, as Mozilla should be recognized in it's own right, by now. A reference to NS may still be appropriate for an acknowledgments or THANKS file, but shouldn't be necessary in the description any longer, IMO. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Undefined Symbol Crashes KDEINIT
On Wed 31 Dec 1969 17:00, Bill Greenwood posted as excerpted below: > Tried submitting this to Bugzilla, but would not take it, > do here it is: > > Trying to start KDE with the latest packages, XFree starts and > a dialog box pops up on the top left corner stating: > Could not start kdeinit > > After pressing Okay, crashes back to console. > > Three errors show, and thet are all related to: libfonfig.so.1 > Stating in part: Undefined Symbol: FT_Get_BDF_Property > > Recently upgraded system from pre 9.1. > > I believe I have all pkgs and deps installed properly. > But if I don't, plz advize and will repair and let you know. I had possibly the same problem. I can't currently start KDE from the konsole, so I had to fire up the dm and use the graphical login for the first time in ages. I assumed it was some personal customization to my system, perhaps the fact that XFree86 was upgraded in the last upgrade session and that sometimes kills the NVidia proprietary drivers, until I recompile them. At least, that's been the case before, and I thought it was this time. However, that was b4 the dm login worked, at which point I forgot all about it until I read this. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Re: [Contrib-Rpm] sgrotum-1.2.6-1mdk
On Fri 12 Sep 2003 07:51, Levi Ramsey posted as excerpted below: > On Fri Sep 12 12:12 +0200, Götz Waschk wrote: > > Am Freitag, 12. September 2003, 12:07:40 Uhr MET, schrieb Thierry Vignaud: > > > > Name: sgrotum Relocations: (not > > > > relocateable) > > > > [schnipp] > > > > > is this really needed in package description ? > > > > I wonder why nobody has complained yet about the package name :-) > > Methinks "[schnipp]" appeared too close to the package name for > comfort... > > Ouch! Well, at least it's "not relocateable"! OTOH, perhaps that turtle should be relocated.. .. On my ISP's newsgroups, there's a current thread about the news admin quickly learning to add the "communications", when in conversation he mentions working with/for "Cox Communications". Without that, he tended to get rather strange looks, and occasional questions about whether his wife minded! -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] um.
On Fri 12 Sep 2003 09:12, Jan Ciger posted as excerpted below: > Svetoslav Slavtchev wrote: > | sound almost great :( > | like in the famous linux browser opera (not that i like it or use it), > | but > | > | "well if you want it for free, you'll have to see some adds, > | but go and get the full version -- noads, cheap " > > That's why I do not use it :-) I don't use it because it's not software libre. =:^) If I wanted proprietary-ware, I wouldn't have bothered moving off of MSWormOS. In fact, if I wanted proprietary, I would have gone with Apple instead of IBM compatible back with my first purchase when 486s first came out. I didn't like proprietary then, so I chose the most open alternative I was aware of. I didn't like it later, so I dumped that alternative as monopolistic and moved to Linux when I became aware of it and able to do so. Anyway.. now that we know it won't be in the screensavers and that it's only a single ad in the installer and some paid links in the browser, I'm actually thinking about other possibilities. Currently, Mandrake, and Linux in general, appeals only to the geeks and power users, who dare to do their own installs, and to the few who buy cut-rate computers at the low end where the $50-100 for the MSWormOS OS can be a quarter of the purchase price of the entire machine. This discussion has inspired me to think what if? What if Mandrake were to become the next AOL, with its 50% share of the internet market, precisely because it DOES cater to the folks that don't know much about computers, and have other stuff in their life they want to do rather than spend the time learning about them. These folks are willing to PAY for the handholding, and, like the vast majority of folks the TV ads cater to, not only don't MIND a bit of ads if it saves them a bit of $$, but actually go out and BUY the stuff in the ads (apparently, or the ad agencies wouldn't be doing multi-million dollar campaigns..). What about making Mandrake the AOL/Earthlink/MSN of OSs? Put the CDs in the store @ 99 cents, and let the advertisers in effect pay the distribution costs. Create two versions of the CD, each @ 99 cents, one that boots from the CD and doesn't affect the hard drive at all, called a demo version, one an intro version that stores a limited amount of stuff in a file on a FAT or NTFS filesystem (umsdos??). A third @ perhaps $10 called a learner version would handle repartitioning and etc and would consist of the two disk d/l version. All these would have advertising, including a not easily disabled (for the level we are talking, anyway) screensaver and possibly a periodically rotating banner in the panel. All but the demo version (since it has no way to store it) would include an upgrade to an ad disabled version for say $10 for the intro version, $20 for the learner version. The latter, not coincidentally, would bring the learner version up to the $30 price of a basic d/l edition boxed set (last I checked..). An additional documentation disk would be available for say $5, or the book for $12-ish. Finally, a "standard" version would be available w/o ads @ the same $30 price of the learner version w/ ads disabled. From there, upgrades would be to the current club and boxed set editions. There'd be current support options as for the d/l version, or a link to a peer support newsgroup available for free. Of course, all this would be GPLed and available for others to hack and create "lite" versions of, but the cost wouldn't be anything extra for Mdk so this wouldn't matter, and without the ads included, there'd be no pay for the stores to distribute it, so no incentive for mass distribution. The entire thing would be pretty much revenue neutral for Mdk at that level, no additional unpaid support, ad sponsors paying the distribution costs, but it would make Mandrake a household term much like AOL or whatever is today, even for those that don't have computers. In fact, if it were teamed with AOL for internet access as one of the sponsors, which shouldn't be to hard for AOL to support since the first two levels would be essentially closed systems with no additional installable software to muck up the support side, it could piggyback on the AOL distribution system, magazines, mailers, the whole bit. Yes, I know.,. pie-in-the-sky, and still linked to ads, but think of it this way, if it WERE to happen, an emergency boot disk in the form of the $10 learner setup would never be more than a computer store away.. and for use "power users", shutting off the ads once installed and running, would be no more than a config file edit or two away, and then on to upgrading to cooker again.. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] um.
On Fri 12 Sep 2003 03:25, Götz Waschk posted as excerpted below: > Am Freitag, 12. September 2003, 03:15:18 Uhr MET, schrieb Duncan: > > On Thu 11 Sep 2003 23:50, Svetoslav Slavtchev posted as excerpted below: > > > i still disslike SuSE, because they use closed installer, > > > and there are no free install CD, and i think i would have > > > similer impression from Mandrake. > > > > If I'm not mistaken, they DO publish source, but it's not GPL > > compatible due to a caveat -- you can make mods and distribute as > > you wish, BUT ONLY FOR FREE AS IN GRATIS, you can't distribute > > versions for which you charge. > > You're absolutely right, that's the licence of yast2 in plain english. > This is the reason that disqualifies SuSE for me and others, as it's > NOT free software, they restrict your freedom too much to make it > usable for stuff like a special purpose distribution. I guess that's (to me anyway) the difference between "closed" and "free". I would agree it's not "free" (libre), but it's not exactly "closed", either. It's open to look at, even without the non-disclosure license that MS forces on folks taking advantage of their "shared source", but it's not "free" of serious restrictions on use. FWIW, that's one of the reasons I haven't tried SUSE either. I prefer "free as in libre" software, and thus, support Mdk in its policy restricting the d/l version at least, to such software. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] um.
On Thu 11 Sep 2003 23:50, Svetoslav Slavtchev posted as excerpted below: > i still disslike SuSE, because they use closed installer, > and there are no free install CD, and i think i would have > similer impression from Mandrake. The free install CD may be a valid point, but the installer.. well, that sort of depends on your definition of "open" and "closed", I believe. If I'm not mistaken, they DO publish source, but it's not GPL compatible due to a caveat -- you can make mods and distribute as you wish, BUT ONLY FOR FREE AS IN GRATIS, you can't distribute versions for which you charge. Thus, it's deliberately not commercially viable to use their installer as the basis for another distrib, in ordered to keep commercial competition down, but if one doesn't charge for it, one could do it, and one is free to do it for their own or company use free of distribution charge, in any case. That's as I've seen it explained, anyway. I haven't bothered to go look at it first hand and see, so it's QUITE possible I have it all wrong. If so, a correction would indeed be appreciated. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Mandrake Web Site Fonts
On Wed 10 Sep 2003 07:33, Felix Miata posted as excerpted below: > The best setting is none at all, or else font-family: sans-serif;. No kidding! The same applies to colors, of course. Some people prefer light on dark, while most web sites seem to default to dark on light. The worst problem is when a site sets bgcolor but not text color, or the reverse, making an assumption about user color setting that may not be true, and causing some folks to get white text on white background (or black on black, for the reverse). If one IS going to set one of the two, one should set BOTH. It's mainly for the color thing that I'm running a personal web proxy, the contribs package privoxy. I have it set up with quite a list of s/bgcolor=f.f.f.// s/bgcolor=e.e.e./bgcolor=11/ s/text=0.0.0.// s/text=1.1.1./text=ee/ etc. (Of course the actual substitutions are a bit more complex than that, but you get the idea.) OTOH, the only font thing I've come across that I had to substitute for was s+ms sans serif(,?)+m\$ sans serif($1)+isg (which disables it, but leaves the telltale m$ version there so I can see the filter activated, if there are issues). Finally, it's worth mentioning that an earlier version of Konqueror would crash on the » sequence if used in a title. Well, not crash, exactly, but make KDE (not just Konqueror) entirely unresponsive to input. One could use the kernel's MagicSRQ keys to invoke raw keyboard, then switch to another VC, from which KDE could be terminated and reinvoked, but that was about it. Thus, I inserted a substitute for that using > > instead, which worked fine. (I've been going to check on it again and bug report if necessary, but I'm a bit behind on updates right now..) I started using personal web proxies with the Proxomitron on MSWormOS, and for a time felt lost browsing the web on Linux w/o it. I tried several, but when that contrib package of privoxy arrived, it was just what I needed! Browsing is a much better experience when it's done on my terms, thanks to a personal web proxy set up to rewrite IMO stupid page designs into something a bit more personally tolerable. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] KDE file associations forgoten after restart
On Tue 09 Sep 2003 15:09, Buchan Milne posted as excerpted below: > This will not work until all desktops use one menu/mime-type system (who > the idiots were who decided to implement one per desktop is something I > would like to find out ...). Your associations will be reset every time > you run update-menus (which happens when you log in, and should happen > after you install a new package). You may be able to put entries in with > the menudrake, I haven't tried. I finally took to creating my own alternative menu file override entries in /etc/menu, copying entries from the mandrake-defaults in /usr/lib/menu to /etc/menu then changing them as necessary. I got tired of the limitations of menudrake such as tiny attrib edit dialogs that show perhaps 15 chars (non-resizable windows) when attribs like kde_opt are commonly hundreds of characters long. I have three monitors @ 1280x1024 each precisely to avoid the "keyhole effect" of small viewports, and that's precisely what the menudrake attrib edit dialog gives me. As well, there's no way in menudrake to duplicate entries, except for creating a new one and painstakingly copying the attribs one by one. On the icons, since it doesn't list the path to the icon, just shows it, it's difficult and sometimes impossible to create a new entry accurately anyway, because you can't find the proper icons! Finally, it's entirely to easy to wipe out a whole slew of changes by saving the wrong config when switching between the user settings and the default settings, in part because menudrake stores all changes in a single file instead of one file for each menu entry, as are the original files. (Yes, I should really file bug reports on all this, but I'm going to wait until post 9.2 since it's in freeze.) All these problems are resolved by doing it the old fashioned way -- copying the config files as necessary and editing them in your favorite text editor, then running update-menus manually. The documentation is where one would expect under /usr/share/doc/menu-, or one can just look at existing entries and figure out what is going on. This sort of customization allows for several improvements. One, I can actually get file associations to STICK, system-wide, and not get over-written each time! Two, I can put my own command line options and other customized attributes in, and have them STICK! Three, the menu items stick around better, causing less problems with khotkeys losing its settings because the menu item disappeared at the last update due to some package change, as invoking a hotkey on a non-existent menuitem causes khotkeys to erase that entry from the hotkey config, so even when I got the entry back, I was having to manually configure the hotkey for it again. With properly modified /etc/menu/ menu file entries, the menu entry remains even if the default package it formerly depended on split out from under it or some such, and the default entry is no longer there. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Advanced configuration tools
On Mon 08 Sep 2003 07:01, Adam Williamson posted as excerpted below: > Besides, GTK+ is already cross-platform, or can be - there's a version > of GTK+ for Windows and builds of Gaim and Xchat for it. Wonder if it > would be possible to port the drak* tools to that? PAN is also being regularly built for "MSWormOS" now, on top of the GTK+ ports. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Suggestion for improved user experience
On Mon 01 Sep 2003 13:27, [EMAIL PROTECTED] posted as excerpted below: > > On Mon, 1 Sep 2003, Buchan Milne wrote: > > See mutray (for KDE at least) and mdk-check-update-gnome (works in KDE > > and GNOME, and probably the rox desktop too), both in contrib. > > It would be a shame not to just enable these by default or at least enable > it if some visible checkbox is clicked. Both those applets are pretty new, AFAIK, introduced into contrib this beta cycle. Yes, there's a place for them. Yes, main and installed for the convenience of newbies by default would be good. No, I don't believe they should be in 9.2 by default. They aren't yet stable/mature/proven enough yet for that, IMO. Leave it in contrib this cycle, consider it for main next cycle, install it by default the third cycle, I think is a decent policy, tho installed by default in second cycle might be fine for these, if maturity and stability warrants it. AFAIK, it's the same deal with urpmi.setup. It may be a bit older, but it was just moved from contrib this cycle. As a setup for urpmi, which is a cli tool, I wouldn't expect it to be core integrated into Mandrake's centralized GUI config system yet. Perhaps a separate menu entry under config, and moving it to main is certainly appropriate for this release, but integration into Mandrake's core config can and should appropriately wait until the next cycle, IMO. One step at a time.. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Updating
On Mon 25 Aug 2003 22:52, Dave Cotton posted as excerpted below:
> On Tue, 2003-08-26 at 05:06, Michael E. Jaggers wrote:
> > The US feed for cooker (at least the sites that I know about) has been
> > busted for a while. It seems that a number of US sites get their cooker
> > from carroll.csc.psu.edu, and either the upstream node is broken, or
> > carroll can't handle the updates.
>
> Many of the mirrors have stale "carroll in updating state" files in
> their directory structure. The problem is how to unlock the situation,
> short of tracking down the updating route of mirrors?
Catching up on the list and I don't know if this is still a problem or not,
but I found that the rpmfind ftp mirror on speakeasy.net was updated when
some other mirrors here in the US were not.
I have separate entries for main and config. Here are the appropriate
portions of urpmi.cfg, with the paths, etc, that you need for urpmi.addmedia:
se.m
ftp://rpmfind.speakeasy.net/linux/Mandrake-devel/cooker/i586/Mandrake/RPMS {
hdlist: hdlist.se.m.cz
with_hdlist: ../base/hdlist.cz
key-ids: 70771ff3
}
se.c
ftp://rpmfind.speakeasy.net/linux/Mandrake-devel/cooker/i586/Mandrake/RPMS2 {
hdlist: hdlist.se.c.cz
with_hdlist: ../base/hdlist2.cz
key-ids: 70771ff3
}
The other US mirror I was using was mirror.mcs.anl.gov, which I noted had that
stale carroll file mentioned.. I originally got into Cooker from RPMFind,
and had been using the SE RPMFind mirror for some time, as one of the fastest
from my location. It isn't always as updated on Mdk anyway as the
fr2.rpmfind mirror is, but it's definitely faster than going trans-atlantic
to fr2 from here, and was **DEFINITELY** in better shape than mcs, last I
checked it. (I'm in the middle of a project and am not updating Cooker right
now, but decided I better catch up on the list anyway, as there were ~700
messages in queue to read!)
--
Duncan - List replies preferred.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety."
Benjamin Franklin
Re: [Cooker] Software submission for the Mandrake distribution
On Fri 22 Aug 2003 03:30, Manoj Joseph posted as excerpted below: > Hi, > > > > but I think it belongs > > > in Contribs. > > > > It doesn't make the requirements, it is not free enough (similarly to > > freedos, which can't be compiled with free software). > > I am new to 'cooker'. I am not sure how things work over here... > Does this mean that you guys won't touch it?? ;) > Could someone tell me how decisions are made over here? Note that I'm just a cooker user/tester, but have been on the list for a bit, so weigh my opinion with that perspective.. Yes, that's basically what it means. It can never make it into the downloadable version, tho it could in theory make it into the boxed/shipped/paid version (but practically, would have to do XP/2K first, and would have to be well tested enough to be something worth being part of the paid-for version). That means this isn't the entry point you are looking for. I had suggested PLF, which does this sort of license encumbered thing, but as others pointed out, they distribute rpms.. Linux stuff, not stuff for MSWormOS. Therefore, it isn't likely to get distributed there either. Perhaps try Suse, or one of the ISV/consultant firms, tho the big ones probably aren't interested due to the fact the big jobs they generally deal with are probably to big to run the dual boots in which this would be useful. A local jobber computer consultant/contractor might be /quite/ interested, however. It might even land you a job with one. Meanwhile, maintaining it in decent view on sourceforge likely remains the best way to grow interest and users. That's my honest opinion.. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Mirror : to be or not to be
On Thu 21 Aug 2003 13:54, cpjc posted as excerpted below: > sorry if I missed something but the Mandrake World is still turning (ie > lots of CHRPM messages in the changelog list) but I couldn't find some > updated packages on the ftp mirrors listed on the Mandrake Cooker site : > kdebase, kdemultimedia,... I went through nearly most of them.. > > So now my cooker box is inconsistent because those files are missing on the > ftp site but are included in the hdlist.cz, so my urpmi --auto-select fails > : no konsole anymore, etc... If you didn't know, konsole is now a separate package, kdebase-konsole. > Any clue for the reason ? > > More important : can someone tell where I could find a up-to-date mirror to > get my cooker consistent ? According to the list, they changed the master server responsible for cooker, and the mirrors went out of sync during the change-over. Hopefully, it will all work itself out in a few days. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] QT massive improvement
On Thu 21 Aug 2003 06:58, Maksim Orlovich posted as excerpted below: > Where did you get this idea? I already said, basic background knowledge from the little widget programming and conversion and documentation of such I've read.. then taking an educated guess based on that and the known facts (the name, and the fact that several folks commented that Qt-only apps worked better). Of course, I also said I may know just enough to build up a plausible sounding but fantastically wrong house of cards.. If that' is so, I'd appreciate you explaining where I got it wrong, and what the right explanation is. However, I'm generally pretty close, tho I've been wrong a couple times too. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] OT: Have you come across free beer? [was somethingelse..]
On Thu 21 Aug 2003 03:49, John Keller posted as excerpted below: > But, as they say, "you only borrow beer". Linux has stuck around much > longer for me, at least... :) Well, unfortunately, what doesn't go to waste, goes to "waist". I don't drink beer (tho Odouls is fine), but I have to much sticking "around" my "waist" already! -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Software submission for the Mandrake distribution
On Thu 21 Aug 2003 03:30, Leon Brooks posted as excerpted below: > On Thu, 21 Aug 2003 03:46, Adam Williamson wrote: > > On Wed, 2003-08-20 at 18:30, Levi Ramsey wrote: > >> Am I the only one who's been waiting for someone to muddy those > >> waters with a beer whose recipe is GPL'd? ;o) > > > > Besides, have any of you ever met anyone at *all* who's come across > > free beer? :D > > I don't drink beer (don't like the flavour, and don't need intoxicants > to have fun), but I have been offered beer for free on many occasions. Aye! Someone else that doesn't!Last time I used the "free as in beer" analogy, I made it "free as in Odoul's!" (Odoul's is a non-alcoholic beer available here in the US, perhaps elsewhere? Here, "NA" legally means less than 1/2 of 1 percent, or one proof, alcohol, by volume, I believe, and NA beer is free from the alcohol tax and proof of age requirements of the "A" stuff.) -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Software submission for the Mandrake distribution
On Thu 21 Aug 2003 04:51, Adam Williamson posted as excerpted below: > On Thu, 2003-08-21 at 12:43, Buchan Milne wrote: > > Leon Brooks wrote: > > > That's a bit short, it's a useful migration tool. > > > > IMHO, no, it's a crutch supporting your use of Windows. > > Shortsighted. For a personal user, migration can be a short term thing. > For a decent sized company, it's very, very unlikely to be; a migrating > environment will very likely be a mixed environment for a reasonable > length of time. In this environment, such a driver makes sense to smooth > the transition process. Actually, no, it doesn't, in any "decent" sized company. Such a company shouldn't be doing dual-boots for the security reasons already hashed out in the thread. If they aren't doing dual boots, then all the data is either on a single-boot computer environment, where this shouldn't be needed, or on a network, where network access will be used instead of local disk fs drivers. There's no case for dual boot in the "decent" sized enterprise, except possibly in experimental non-production environments without any critical data on them anyway. Rather, it's the SOHO sized businesses, where essentially every employee with access is trusted and a dual boot system is therefore a manageable risk, and in non-business consumer installations, that a driver such as this might make sense. OTOH, one only has to look at the number of big companies that had serious problems with slammer and blaster to know what should be done from a security perspective and what is REALLY done are often two VERY different things.. How someone can spend $1000 on the core OS software license alone for an MSWormOS server (accurate call in this case), and not spend the $50 bucks for a simple NAPT based security appliance, or a few hundred $$ for something a bit fancier and higher capacity if necessary, to protect that investment, is beyond me, but it's obviously a common practice. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Software submission for the Mandrake distribution
On Wed 20 Aug 2003 07:25, Buchan Milne posted as excerpted below: > Well, the first question I have is, can this software be compiled from > source using only free software available in Mandrake (main + contrib)? > If not, then it can't really be included. What about PLF? I know they handle quite a bit of stuff that contrib can't, due to the licensing requirements. I don't quite understand all they do and where they draw the lines, but Manoj, if you haven't, consider investigating PLF, as it may be just the type of place for such a thing. As for the driver, I see a very practical use for it. However, one of the reasons I'm on Mandrake is because I support their software libre philosophy, and the others are correct -- given the situation with the DDK, this doesn't belong in the distrib itself. However, PLF? Maybe. I definitely see a practical use for the driver, altho again, the others are correct in that without 2K/XP support, it remains an interesting sourceforge type project, useful for those that need it, but not really practical for a distrib, even licensing concerns aside. That's my opinion, anyway. As well, the current FAT solution, with remounts and symlinks as necessary to integrate it transparently into the Linux fs tree, as I mentioned in my other post to the thread, is close enough to an equivalent solution practically, and a far cleaner software libre solution philosophically, that it'd be preferable here. Still, I could imagine myself using your driver for awhile, as a newbie, precisely for the purpose you stated -- as a "migration aid". (I should mention that I upgraded directly off of Lose98, as the far lesser of two evils as compared to selling my soul to MS with the tradeoffs in privacy they demanded with XPrivacy, so the FAT32 solution was native and natural, here. Recently, for the first time in 6 months, I booted MSWormOS, to uninstall most of the programs and delete much of the MS-centric OS and programming data and etc. I'd accumulated over the decade I "did windows", then shrunk the partition, leaving it there directly bootable on its own disk, should Cooker crash on me and I need a way to d/l a workable Linux install, again, or should I need to test a bug in hardware vs. drivers. Thus, it's finally relegated to a role very similar to monitor/rescue mode on my router, and my old DSL modem, in obscurity waiting in case the REAL OS dies, somehow, beyond easy direct resurrection... If I upgrade to a dual Athlon-64 solution as I'd LIKE to, later this year or early next, I'll probably then delete the last vestiges of the proprietary-ware that was my first and ten year computer home, NEVER to return.. As it is said.. "When I was a child, I thought as a child, but when I became a man, I put away childish things." (Paul)) -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Software submission for the Mandrake distribution
On Wed 20 Aug 2003 23:05, Manoj Joseph posted as excerpted below: > But transferring files is not the only use. A Windows user usually has > Windows only application that continue to be used even after switching > to dual-boot. > > Those applications don't get thrown out - at least for a while... > Getting those applications to access the ext2 partitions is *useful*. The reverse of that could work about as well, especially with the remount possibilities of newer kernels and mount, or symlink possibilities, for that matter. IOW, set up the FAT partition, creating "subfolders" as appropriate for the various points in the Linux fs tree you wish to share. Then remount the FAT partition at the appropriate places or point symlinks from the appropriate places as necessary under Linux, and VWALLA! you have files transparently accessible from Linux at their usual tree locations, AND accessible from MSWormOS. .. For a decade I labored under MSWormOS without the magic of symlinks. The first five years, I didn't know what I was missing. The next three, I could conceptualize it but didn't really understand the implications. The last two, I had discovered a utility that made it more or less possible -- at least for "folders". Then I upgraded to Linux just under two years ago, and I'm STILL appreciating the amazing abilities of symlinks, tho I know they don't /always/ work /quite/ like the actual files would. IMO, many/most *ix users don't realize just how flexible they can be. as they offer solutions time and again for my weird partitioning and location dilemmas. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] QT massive improvement
On Wed 20 Aug 2003 05:40, Mark Watts posted as excerpted below: > > > > Laurent built Qt with KDE widget support in 3.1.2-13mdk. It doesn't seem > > to help Qcad though, but a few other Qt-only apps do look better. > > /me wonders how KDE was working at all if qt wasn't compiled with KDE > widget support... > > Evidently I don't understand qt ! I wondered as well.. until I thought about it.. KDE calls its own widgets, knows about them and uses them as necessary. Qt, OTOH, didn't know about or use them. Adding KDE widget support allows Qt-only (thus, not KDE specific) apps to ALSO use the KDE widgets. It doesn't directly affect KDE, except that Qt is a lower level library system than KDE, so it could in theory make things a bit more efficient. Since Qt-only apps won't know about KDE, they will call the general Qt widgets, but with KDE widget support, Qt uses the KDE ones directly now rather than its own, in some (all possible??) cases. The benefit here would be that Qt is designed for cross-platform incl. MSWormOS use, and their widgets would by necessity be a compromise based on that. In a more "KLX" (KDE League I believe it is term for KDE on Linux using XFree86) native environment, the KDE widgets have been designed to look better and be more refined than the Qt general widgets, so the benefit here is that Qt-only apps get the benefit of the nicer/newer KDE refinements, including anti-aliasing, etc. At least, that's an educated guess based on the little widget kit programming and conversion knowledge I have, which might be just enough to get a plausible sounding but totally wrong impression of things, I must admit. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Cooker installation report (not good)
On Sat 16 Aug 2003 05:23, Frederic Soulier posted as excerpted below: > 3) Missing KDE programs (eg Konsole) Konsole was just split off of kdebase. It's now a separate package, kdebase-konsole, or some such. I think it should still be installed by default, but either it isn't tweaked to do so when selecting KDE yet, due the the newness of the split, or others think otherwise, it would seem -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] MakeCD is broken - so if problem database
On Fri 15 Aug 2003 09:57, Chris McBrien posted as excerpted below: > Now here's a real head-scratcher. I got past that point by installing > various perl rpms. I should mention I am building cooker from a > Mandrake 9.1 installed from DVD. > > Now I get this error, even though slocate Spec.pm shows > '/usr/lib/perl5/5.8.0/File/Spec.pm', so I'm assuming the base perl > package with that file is already installed. Keep in mind that slocate doesn't use a "live" view of the system, but rather, a view from the last time the db update for it was run (by default from a crontab script entry under daily and weekly, here). Thus, if you are updating your system, it may be that was removed but the slocate db hasn't been updated to reflect that, yet. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] installation: what are the file labels
On Fri 15 Aug 2003 09:39, Keld Jørn Simonsen posted as excerpted below: > I have a question for how the file labels under the installation are > being determined. > > One of the times I forgot to deselect my /var partition from mdk 9.1, > that is, because there was a /var label on that partition, the > installation partitioning suggested that I mounted that partition on > /var - and yes, then my rpm database for MDK 9.1 was gone... :-( > > I then tried to figure our how to change the file system labels, > but till now to no avail. I tried e2label and reiserfstune -l I'm guessing it's simply following the path from the boot loader to root, and reading /etc/fstab to see what you currently have mounted where, then suggesting that. Unless I somehow missed something or read your post wrong, you should be able to change the "labels" (mount points) by changing the mount points for the various partitions either there, or by using diskdrake. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] KDE 3.1.3 Autostart broken?
On Thu 14 Aug 2003 03:38, Aleksander Adamowski posted as excerpted below: > So to summarize, it's sort of a bug in KDE - it ignores Autostart links > to applications that don't have a name for currently used language. This > is bad since one can create a desktop entry, then switch to a differenet > language. > > With the current version of KDE and my language settings, when I create > a link to application, it gets both a "Name" and "Name[pl]" attribute, > but I'm not sure that other combinations of language settings couldn't > create one that only has "Name[pl]" and no "Name"... I expect the bug was really in whatever you used to create the desktop entries w/o the general name attribute, altho that may have been an earlier possibly cooker version of KDE. I don't actually see the ignoring name entries without a general or current locale settings as a bug, since it's quite possible one may wish to start some things when running one language, others when running another, and this makes that possible to manage automatically. Keep in mind that one of the design philosophies behind KDE is that as much of it as possible should be available to be customized by the user (as compared to say, Gnome, which emphasizes simplicity over customizability, thus its simpler configuration applets that leave out the ability to change a lot of stuff easily that can be changed in KDE, while KDE often gets the complaint by usability experts that its to hard to find the setting one WANTS to change among all the others), and this feature would give that power to the user. Again, IMO, the real bug was rather that these entries didn't have a general name attribute by default, as they should have, which would have generated the expected default behavior. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Rpmdrake inspecting of config files
On Wed 13 Aug 2003 08:04, John Allen posted as excerpted below: > On Wednesday 13 August 2003 11:31, Guillaume Cottenceau wrote: > > John Allen <[EMAIL PROTECTED]> writes: > > > Rpmdrake should do a diff of .rpmnew/.rpmsave and if no changes are > > > detected, zap the rpmsave, or use .rpmnew automatically. This will > > > reduce the amount of files you have to manually inspect. > > > > Is it normal at first place that a .rpmnew is created which > > contents is the same as the config file? > > Well I'm getting lots of them when I use rpmdrake to do updates. I know it > is the underlying rpm that creates .rpmsave, and .rpmnew files, but > rpmdrake could just use the .rpmnew, and delete the .rpmsave when there are > no actual differences. I am sure someone will correct me if I'm wrong, as I'm by no means an expert, but this is the conclusion I've come to by watching the behavior over various upgrades here. 1) RPM stores the md5 sum of the various files in a package in its database. One can get a report on the files that have changed from those in the original package by doing an rpm -V , with the returned format listing consisting of any file that's changed, and a flag list of what aspect has changed, date, size, md5sum, etc. 2) As far as I've been able to conclude, at upgrade time, rpm checks config files, and directly replaces any that return as unchanged from the last package. Any that return as changed aren't replaced, but rather, rpm installs the new config file as file.rpmnew, retaining any customizations you've made to the configuration. Of course, upgrades may include new or changed features, and a manual reconciliation and merge of differences may be necessary. However, that's far better than totally and arbitrarily overwriting any customizations you may have made, while still leaving a copy of the new uncustomized version conveniently available where one can view it and incorporate any new config changes into the old customized version if desired/necessary. 3) The same basic process occurs at rpm uninstall, with unchanged config files uninstalling cleanly, since if one installs the package again, they just get non-customized installed once again, but any config files that were changed are not removed, but rather renamed with the .rpmsave extension. Thus, if the package is reinstalled, one can easily recustomize it if necessary by just replacing the uncustomized config file with the rpmsave version. Of course if a newer version is installed, a manual merge or reconciliation may be necessary, as is the case with upgrades and .rpmnew files. Thus, if those files are being created, it's a sign that rpm thinks the original config files were modified/customized and thus doesn't want to overwrite them. Of course, keep in mind that you may not have edited them directly for them to be changed (think a gui config helper app changing them), but if they indeed haven't changed, and rpm is constantly installing duplicate rpmnew config files, you may have a corrupt rpm database, which thus thinks that even unchanged config files are different. Again, one can verify what RPM thinks has changed on an individual package by using the verify package switch (-V) on rpm. If your database is indeed corrupted, a --rebuilddb or similar may be required. See the man page for the appropriate switch and its correct usage. Hope that helps, and again, I don't claim to be an expert, and am only reporting what I've observed and the conclusions I've reached based on that that make the most sense to me given what I've seen. Again, should any of this be wrong, please someone, correct me as necessary. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Re: [CHRPM] perl-URPM-0.93-1mdk
On Wed 06 Aug 2003 12:12, Levi Ramsey posted as excerpted below: > On Wed Aug 06 20:00 +0200, François Pons wrote: > > * Wed Aug 06 2003 Fran?ois Pons <[EMAIL PROTECTED]> 0.93-1mdk > > > > - added URPM::Signature for handling armored gpg file and > > internal rpm pubkey. > > Does this mean that urpmi won't prompt on PLF packages? > > If it does, then I worship the ground on which you walk... It hasn't been prompting me every since I updated the RPM GPG database with the PLF key (as we originally had to do with the Mdk keys as well, when rpm 4.2 came out, as the initial packages didn't import them automatically). -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] NVidia drivers
On Wed 06 Aug 2003 13:05, [EMAIL PROTECTED] posted as excerpted below: > On 6 Aug 2003, Kamil Rezac wrote: > > Hi! > > > > I've just tried to run The Gimp (first run, it prepared to create the > > ~/.gimp dir) and the X just locked-up (L in ps) (no keyboard response, > > the mouse cursor moved and xmms played;) I've installed latest NVidia > > drivers a couple days ago, mybay that's the problem Has anyone the > > same experience? > > perhaps, try ssh-ing into your box and run a trace on X. If it is looping > all the time with sigalrm, then yes, it is a bug with nvidia drivers I am > experiencing as well. > > (I thought they fixed it, but all they did I think is disable renderaccel > by default, which makes it less likely to occur, but bug is still there, > at least IMHO, but who can tell without source..) I was experiencing the same thing in KDE a couple KDE builds ago, but haven't real lately. However, in most cases anyway, I'm able to use the magic SysReq key combo (Alt-Srq-R, I have just the one computer so don't have anywhere else to log in from) for raw keyboard, and then switch to a different VC and kill (sigterm, not sigkill) kwrapper to bring X down at least a bit more gently. Note that my system is not the usual Cooker system, either in what's installed, or how I use X. First, I'm running a kernel.org kernel, not Mdk's. Second, I'm running Xinerama with three monitors, two of which are on my Nvidia GF2 card (necessitating running their driver, unfortunately, since the software libre nv driver couldn't drive dual monitors, last I checked, that's MY reason for having to use NVidia rather than NV), the third on an old S3Virge PCI card. Further, I have init 3 console level set as default, and start X/KDE from a console directly logged in as a user, rather than using a DM to log in from X. Therefore, kwrapper is a child of startkde, which is a child of xinit, which is (indirectly) started from a script launched from a console login, with said script starting KDE in the background, sleeping a few seconds, disowning its children, then exiting so I get the VC back for use if I desire. I thought it was the cooker build of KDE, not the NVidia drivers, but I might be wrong, and will try a trace next time, since you suggested it.. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Re: [Contrib-Rpm] scorched3d-35-1mdk
On Mon 04 Aug 2003 12:24, Per Øyvind Karlsen posted as excerpted below: AdamW wrote.. > > Can I have your babies, Mr. Karlsen? :) > > que? I'm sensing a potential cross-cultural disconnect, here.. For those who aren't familiar with the meaning of this question.. "Can I have your babies?" is an allusion to a stereotypical saying of (typically female) rock groupies and others.. infatuated and idolizing the person they view as almost a god.. Here, of course, it can't be taken quite so literally, but can be taken to mean something like "I am forever in your debt," or more literally, "I owe you one, Thanks more than words can say!" Hopefully I did that explanation justice.. Does that make the intent clearer? (Sort of like the "pulling my leg" allusion I recently mentioned, I THINK it was on the Mdk list.. ) -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] New Bootsplash
On Tue 05 Aug 2003 11:36, Benjamin Pflugmann posted as excerpted below: > On Tue 2003-08-05 at 19:22:22 +0200, [EMAIL PROTECTED] wrote: > > Guillaume Cottenceau <[EMAIL PROTECTED]> writes: > > > Are we allowed to send a non-translated product in France? I > > > > s/send/sell/. > > > > Neurons are going crazy when run at external temp. of 38.5 > > degrees I guess. > > Yeah, whenever it gets that hot, my thinking tends to grind to a halt > and wonder if I have a bit of troll blood[1] running in my veins. ;-) Never move to Phoenix, Arizona, USA, then. Summer highs here normally run 45 degrees C, with 50 C the record high, set several years ago. Even the lows are not unusually 34 C. As Phoenixians say, "But it's a DRY heat." As others say, "Yes, but so is the surface of the sun!" As *I* say, "Phoenix, the city that Air Conditioning built!" .. A "mere" 38 degrees? That's "unseasonably cool!" A good day for outside work! Seriously, on days below about 30 degrees here in the summer, which do happen occasionally, some folks are getting out the sweaters! -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] hd.img without floppy ?
On Wed 06 Aug 2003 19:47, Pierre Jarillon posted as excerpted below: > Le Jeudi 7 Août 2003 00:57, Frank Griffin a écrit : > > Just an idle, uninformed question, but is there any way to tell a > > Mandrake install boot (whether from CD or floppy with maybe old hd.img > > on it) to "reboot-in-place" using the hd.img from a local disk cooker > > mirror ? The object being not to have to create new hd.img boot > > floppies all of the time... > > This become an important question. More and more computer are shipped > without a floppy. Not because of its price, but only because floppy is now > useless or impossible (like VIA mini-ITX). Well, unless you have net booting working, you need either a floppy or a bootable CD. Since it's a good idea (and cheap) to burn at least the first CD ISO for rescue purposes anyway, and that boots and can "net install" from a local cooker mirror, I don't see a real issue (problematic laptops with removable drives where the CD isn't recognized properly, aside). -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Re: [CHRPM] perl-URPM-0.93-1mdk
On Wed 06 Aug 2003 14:41, Levi Ramsey posted as excerpted below: > On Wed Aug 06 13:18 -0700, Duncan wrote: > > On Wed 06 Aug 2003 12:12, Levi Ramsey posted as excerpted below: > > > On Wed Aug 06 20:00 +0200, François Pons wrote: > > > > * Wed Aug 06 2003 Fran?ois Pons <[EMAIL PROTECTED]> 0.93-1mdk > > > > > > > > - added URPM::Signature for handling armored gpg file and > > > > internal rpm pubkey. > > > > > > Does this mean that urpmi won't prompt on PLF packages? > > > > > > If it does, then I worship the ground on which you walk... > > > > It hasn't been prompting me every since I updated the RPM GPG database > > with the PLF key (as we originally had to do with the Mdk keys as well, > > when rpm 4.2 came out, as the initial packages didn't import them > > automatically). > > I've attempted numerous times, using different downloads of the PLF key, > to import into rpm... no dice. Did you read the man page and import the key using the procedure (and type of key=ascii-armored) there? I've had no problems doing that. Note that at least originally, each key had to be within its own ascii-armored file, not several combined into one file, or it could corrupt the RPM db. If you've tried multiple times and did it wrong say the first time, perhaps that's what happened and it will import no new keys, tho perhaps the damage isn't so bad and the mdk keys continue to work. Other than that, about all I can say is it worked here, which doesn't of course offer any explanation of why it might fail there, unfortunately. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Re: kde splitting: some problems
On Fri 08 Aug 2003 16:14, Greg Meyer posted as excerpted below: > On Friday 08 August 2003 02:21 am, Laurent Montel wrote: > > > kdebase requires kdm, meaning you can't install kde without kdm/mdkdm > > > > kdebase will require all the time kdm. > > Doesn't it make more sense for kdebase to require dm and have all of the > kdm/gdm/xdm/mdkkdm provide dm? Especially if mdkkdm and kdebase-kdm are > separate packages. Why require a dm at all? There are those of us who prefer booting init 3, then starting kde from a console, avoiding the dm. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] kdeutils update?
On Fri 08 Aug 2003 16:56, Quel Qun posted as excerpted below: > What is the point of splitting if everything is needed? If kcharselect > is broken, I can force the others and keep the old kcharselect? But will > it still work with the new libs? This is splitting for the other end of the chain, I believe. IOW, once all split out and the various dependencies worked out so there are no longer issues there, it will allow an update to an individual program and an individual rpm, w/o having to update a "monster size" rpm with all the other non-updated programs in it as we have to do now with kde. It would also, for those that know what they are doing, allow a pick&choose on the install side as well, with folks being able to install pieces where they now install everything. Thus, as in the kdm/mdkkdm threads, one could install substitutes or none, tho that might mean forcing the install. In that case, one wouldn't use kdebase, say, but the individual kdebase-konqueror, kdebase-konsole, etc. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] urpmc-1.2-2mdk
On Tue 05 Aug 2003 04:08, Buchan Milne posted as excerpted below: Duncan wrote.. > > With software libre that shouldn't be a problem. > > This has nothing to do with the freedom or otherwise of the software, it > has to do with software patents in many cases, and copyright (not > license) violation in others. What I'm saying is that whatever issues there may be should then not involve Mdk.. If someone creates an SRPM with --with options so it can be "PLF-ified", and submits it to both Mdk contrib, and PLF, the latter with the appropriate --with options enabled for the binary package, they do so as an independent agent. Mdk is just using their SRPM without the appropriate options enabled for the binary that make it questionably legal. What said independent agent chooses to submit elsewhere, or that said submitted software source rpm has the ability to compile a binary of questionable legality shouldn't be a problem, so long as Mdk is just using a contributed srpm, and ensures that the binary it uses doesn't contain the questioned code. The problem is a bit dicier with paid employees doing so, but depending on how their contract is worded, it may be the same thing, effectively, only that they get paid to submit the Mdk ones, but still whatever else goes on is theirs to do as an independent agent/consultant. OTOH, if the company claims intellectual property rights to anything developed by said employee.. THEN there's a problem, but one would think a decent open source company would realize the problems with such an approach and avoid it. OTOH, the "never heard of it", or heard of it, but didn't know the reference, for those frequenting this list, since it's mentioned here on occasion and the never heard of it probably isn't absolutely credible, for core employees IS probably the best approach.. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] urpmc-1.2-2mdk
On Mon 04 Aug 2003 16:24, Adam Williamson posted as excerpted below: > On Mon, 2003-08-04 at 22:24, Ben Reser wrote: > > > I'd be really surprised if Mandrake was > > shipping packages with PLF changelogs in it because that defeats the > > purpose of saying they aren't connected. > > Mind you, so does using identical SRPMs...maybe it's just an incredible > coincidence? :) With software libre that shouldn't be a problem. It's perfectly legit for someone to make an SRPM with build-options for both, and put it in contrib. It should also be perfectly legit, depending on company policy, for main packages to be done the same way, even by paid employees, recognizing their contribution to the larger community as well as Mdk. Of course, IANAL.. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] dm - prefer kdm or gdm
On Sat 02 Aug 2003 02:53, Adam Williamson posted as excerpted below: > On Sat, 2003-08-02 at 06:31, Duncan wrote: > > The term "a lot" is two separate words (and isn't considered formally > > correct either, BTW, "altho" colloquial usage is recognized). It means, > > as you were > > What the hell do you mean, "isn't considered formally correct"? I've > never seen any authority at all that considers "a lot" to be colloquial > or vulgar. It's perfectly standard English. http://web.uvic.ca/wguide/Pages/UsAlot.html It seems to be moving into mainstream usage. Several years ago, it was considered informal or colloquial usage. Most online dictionaries at least now omit that caveat, altho I did find one that still had it (dated 1995, when that classification was a bit more common, so no real surprise there). University of Victoria (BC, Canada) Writer's Guide http://web.uvic.ca/wguide/Pages/UsAlot.html A lot / Alot / Allot A lot means "a lot": "A lot of pancakes." Note that this is an informal expression. Allot means "to divide" or "to give out": "They allotted six square feet per family." Alot means nothing, and therefore is not to be used under any circumstances. [...] Copyright, The Department of English, University of Victoria, 1995 This page updated September 22, 1995 I found that listed on OneLook, along with a bunch of other dictionary listing links, here:: http://www.onelook.com/cgi-bin/cgiwrap/bware/dofind.cgi?word=a%20lot - Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] dm - prefer kdm or gdm
On Fri 01 Aug 2003 21:39, Joe Baker posted as excerpted below: > On Fri, 2003-08-01 at 21:01, Gary L. Greene wrote: > > On Friday 01 August 2003 09:34 pm, Joe Baker wrote: > > > For installations where there are allot > > > > [] > > That certainly helps allot. I was going to reply to this privately, as it could be more appropriate there, but then realized this is common enough to warrant public posting.. This isn't intended to be a spelling flame, or to embarrass anyone, as someone kindly pointed it out to me as well, for which I am grateful, as it is an all to common and understandable mistake. The term "a lot" is two separate words (and isn't considered formally correct either, BTW, "altho" colloquial usage is recognized). It means, as you were attempting to use it above, "a large quantity of", or "frequently". The term "allot", OTOH, comes from the old idea of casting lots.. It means to distribute or portion out. Example use as in a last will and testament: "To each of my three children I allot 25 percent of my estate, with the remaining 25 percent to be allotted equally between the following five charities, five percent to each." In my case, and I suspect most others where this mistake is made as well, I originally attempted to write "alot", but the spell checker didn't like that, and offered "allot". Many spell checkers won't offer "a lot", because it is two separate words, tho the meaning of the two together is different than the separate words alone. (Yes, "tho" is deliberate. ) I knew "allot" didn't "look right" as used, but until it was pointed out to me, I couldn't explain what was wrong with it.. Hopefully, my pointing it out here will be as helpful to others as having it pointed out to me has been. That is certainly the spirit in which I am writing this, anyway. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] urpmi just keeps adding packages - not removing them
On Fri 01 Aug 2003 06:18, John van Spaandonk posted as excerpted below: > Before latest upgrade (1-8, 13:00, ftp.uninett.no): > > [EMAIL PROTECTED] downloads]$ rpm -q kdebase > kdebase-3.1.2-30mdk > kdebase-3.1.3-3mdk > > After this upgrade: > > [EMAIL PROTECTED] downloads]$ rpm -q kdebase > kdebase-3.1.2-30mdk > kdebase-3.1.3-3mdk > kdebase-3.1.3-4mdk It seems to be working fine here. All I have listed is 3.1.3-4mdk. Thus, I'd guess your rpm database is corrupted and may need rebuilt, unless of course others are duplicating that but I'm not for some reason.. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] weird curl/urpmi problem
On Fri 01 Aug 2003 03:35, François Pons posted as excerpted below:
> Kim Schulz <[EMAIL PROTECTED]> writes:
> > I wanted to use curl insted of wget for the updating of my urpmi
> > hdlists, but curl gives me alot of errors:
> >
> > retrieving source hdlist (or synthesis) of "noo1"...
> > curl: option - is unknown
> > curl: try 'curl --help' or 'curl --manual' for more information
>
> This is not normal, what version do you have of curl, urpmi ?
I get this here with my plf mirror (configured using urpmi.setup), but not
with the main and contrib mirrors. Thus, it may be some weirdness in the PLF
name or some such. It could also be that I FTP plf, but rsync the others..
Here's my urpmi.cfg in case it's useful.. (BTW, is there a list of the
options that can be put here as I have these two?)
{
verify-rpm: 1
allow-force: 1
}
en.p ftp://ftp.easynet.fr/plf/cooker {
hdlist: hdlist.en.p.cz
with_hdlist: hdlist.cz
list: list.en.p
}
mag.c rsync://mirror.mcs.anl.gov::Mandrake-devel/contrib/i586 {
hdlist: hdlist.mag.c.cz
with_hdlist: ../../cooker/i586/Mandrake/base/hdlist2.cz
}
mag.m rsync://mirror.mcs.anl.gov::Mandrake-devel/cooker/i586/Mandrake/RPMS {
hdlist: hdlist.mag.m.cz
with_hdlist: ../base/hdlist.cz
}
sn.m rsync://ftp.sunet.se::Mandrake-devel/cooker/cooker/Mandrake/RPMS {
hdlist: hdlist.sn.m.cz
with_hdlist: ../base/hdlist.cz
}
sn.c rsync://ftp.sunet.se::Mandrake-devel/cooker/cooker/Mandrake/RPMS2 {
hdlist: hdlist.sn.c.cz
with_hdlist: ../base/hdlist2.cz
}
--
Duncan - List replies preferred.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety."
Benjamin Franklin
Re: [Cooker] urpmi - segmentation fault (long mail)
On Wed 30 Jul 2003 10:56, Olivier Thauvin posted as excerpted below: > Le Mercredi 30 Juillet 2003 17:42, John van Spaandonk a écrit : > > My reply to John is somewhere in the mail, other guys can simply delete it. > I want to know how many time he need to find it ;) While I agree with your suggestion to clip unneeded text, finding the reply shouldn't be hard provided the quote levels are properly colored. It wasn't hard here finding your reply in pages and pages.. But then again, I'm a bit used to that, from reading newsgroups where folks all to often don't trim, so my eye easily scans for the color differences.. .. Your headers state kmail, which is what I am using as well, so unless UR using b&w or don't have the colors well configured, it should be EZ! (Of course, the scroll wheel on my mouse helps too.. I was at a friend's house not long ago and kept trying to find the non-existent scroll wheel!One doesn't realize how much a part of the normal computer interface it has become for one, until it suddenly doesn't work! > > 46:kdeadmin-kpackage > > ## 47:libkoffice2 > > ## > > 48:fonts-ttf-west_european### > >## # 49:gnome-vfs2 > > Next, made a bug report if possible, and cut the uneed lines... > This mail is very too long. > > > ###### 50:libg-wrap1 > > ## 51:libfltk1.1 > > RPMS]# -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Re: Pb in your mdk packages (fwd)
On Sat 26 Jul 2003 08:58, Leon Brooks posted as excerpted below: > On Sat, 26 Jul 2003 04:27, Warly wrote: > > So the third time is the good one. > > I18n issue? (-: "Third time lucky" :-) The /proper/ i18n usage should probably be "Third time's charm." =:^) "Lucky" seems to indicate "charm" translated into some other language, then translated back.So does "is the good one", but the comparison isn't quite as direct, so the usage contrast not quite as abrupt and jarring. (Reminds me of the time growing up in Kenya (as a missionary kid), my mom used the idiom meaning joking, "You are pulling my leg!" The poor guy she was talking to was offended and thought she was claiming an improper touch! Oh, the intricacies of language interaction!) -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] naming policy
On Sat 26 Jul 2003 13:10, Guillaume Rousse posted as excerpted below: > Ainsi parlait Michael Scherer : > > > The package ordering through the rpm groups should be > > > sufficient. > > > > But, the ordering is only accessible with rpmdrake ( easily accesible ). > > nope, urpmi output is ordered too :-) Doesn't that require bash-completion? And what about those using other shells? -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Update speed of progress bars
On Sat 26 Jul 2003 08:53, Leon Brooks posted as excerpted below: > It updates the screen by sending X commands. If there are a lot of these > commands, X has to do a lot of work. Not noticeable except across (say) > an ADSL or slower link, when you're remotely administering. If you can > make a read-entry limit itself to flagging that a change has happened, > and then use a timer thread (sleep() signal, for example) to only fire > off an update max twice a second, this will cure it. For slow links, perhaps a text based interface would be better. One of the advantages of the drake tools is that many of them have text based interfaces as well. I, for one, have missed this in menudrake. (I have no reason to do remote admin, but it would be handy to be able to run menudrake from the console outside of X.) Lately, however, I've been getting frustrated with menudrake anyway, as it is just to big and clunky to easily do the modifications I wanted. Rather, I read up on the menu documentation, and began copying the individual default menu entry files from /usr/lib/menu (the default location) to /etc/menu (the overrule location), then changing them there as necessary, then running the update-menus command from the console. Not only can this be DONE from console, but it's far easier than editing the individual item attributes one at a time, in an unresizable edit window with text boxes only about 10 char wide, FAR to small to see even an entire kde option, let alone the entire line one has to use because they are all crammed on a single line. (The same goes for long strings of mimetypes, as another example.) When I edit the indiividual files, I can make use of the line continuator to split a single entry onto multiple lines, as necessary, in addition to being able to see 100+ characters on one line rather than only a 10 char or whatever narrow edit window. Also, having the individual menu entries in individual files is far easier to handle than having the binary choice of system default menu vs customized menu, with customized menu being suddenly erased if one should make the mistake of switching to default to check out an entry there, and save that, with no option of reverting to the former customized menu! Of course, as I write this.. I realize I should be filing bug reports on these issues, instead of finding my own work arounds and leaving others to do the same. I guess someone has some work to do, and that someone would be me! Anyway.. As I was saying, for remote work, try working with the individual text files and with update-menus, rather than the graphically intensive menudrake. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] dnotify startup script
On Tue 22 Jul 2003 01:31, Andi Payn posted as excerpted below: > 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..."? Think like certain apps (or users) from a certain closed OS.. "Type" is conveyed by file extension. Therefore, since the original filename and extension is mentioned, so is the "type". MIME-Type??? What's that?? Text/Plain?? That's the format, not the file type. The file types in question were of course "init" and "sysconfig".. Were you expecting files of that type? .. All according to the common parsing rules of this very common closed OS, of course.. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
On Fri 18 Jul 2003 08:53, David Walser posted as excerpted below: > Yeah, SDL definately does try the DSP's before going to arts, in fact it > goes farther than libao does and looks for more than one DSP, which is > pretty cool. I might see if we can make a similar adjustment to libao. > > Anyway, given that SDL does this autodetection, absolutely no SDL apps > should now be using soundwrapper. Are there any that are? I don't know whether it's soundwrapper, or something else, but dosbox is an SDL app that still fails to work, from my normal user, anyway. (I run ARTS and it will have just been active since I have KDE set up with an app-launch sound that will have presumably just played or still be playing.) It works fine if I run dosbox as root, which implies a permissions issue somewhere. However, I did the PAM mod (as mentioned in the fast-user switching thread) to 660 from 600, and that didn't help, and I don't really know where to go from there.. Yes, the normal user in question IS a part of the audio group. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] split lists?
On Fri 18 Jul 2003 09:53, Buchan Milne posted as excerpted below: > I think the biggest demand for a split list was coming from those > interested in the server aspects. It could also involve those NOT interested in the server aspects, as some of the biggest threads are server related. I am such a one. Personally, I could do without most of the kernel discussion as well, as I use a kernel.org self-compiled kernel and no initrd (altho I've been following the 2.5/2.6 discussion with interest, trying to decide when I want to switch), and without the install stuff for the most part, since I constantly upgrade. Thus, I support the general idea of a split, as it would certainly make life a bit easier for me. However, I understand enough of the practical implications to know a split might not work that well in practice, even for me. Still, the idea of having servers and install on separate lists which I can ignore, and kernel on a list which I can filter more intensely and check maybe weekly rather than almost daily, IS pretty enticing. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Re: [BUG] squid-2.5.STABLE3-1
On Thu 17 Jul 2003 15:05, Norman Zhang posted as excerpted below: > Hi, > > >> [EMAIL PROTECTED] nzhang]# rpm -Uvh squid-2.5.STABLE2-2mdk.i586.rpm > >> Preparing... > >> ### [100%] > >>1:squid > >> ### [100%] > >> [EMAIL PROTECTED] nzhang]# rpm -Uvh squid-2.5.STABLE3-1mdk.i586.rpm > >> error: failed dependencies: > >> perl(Authen::Smb::Smb) is needed by squid-2.5.STABLE3-1mdk > > > > I have noticed that ... how come we didn't have this message before > > ... or maybe this package has just gone from the distro ... > > I does sound funny. I checked CPAN perl-Auth-Smb has been changed since > June 7, 1999. Why would someone take that out of the distro? > > > Maybe I should add the perl-Auth-Smb package ... > > Please do. I will go test it out. Are you sure it isn't included in one of the other Mdk packages? The perl dependencies have been being reworked since the new RPM, to take advantage of some of the new features available and make automation of dependencies on the developer side far easier. Most such new unsatisfied dependencies, then, have been due to folks updating what they have access to to require the new dependencies, before the core packages they may NOT have write access to have been updated to provide them. This is just part of the growing pains of Cooker, to be expected in an alpha state distrib program, so nothing to worry about at this point. There are two ways to proceed with the install and test to see if that's the situation. If it's not something you use often, you can just urpmi --allow-force and force the install (or do the equivalent rpm call directly), then see if it works. Otherwise, you can check the dependency files manually one by one to see if they exist and are in a location where they can be found. I've done both. What I'm thinking is that if this just appeared, it isn't likely to be that the dependency files aren't there in reality, because as you noted, it doesn't make sense. It's far more likely that this is a dependency update thing, particularly since we already know there ARE and have been such issues going on with perl and Cooker in this round. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Re: Re: Re: Re: [CHRPM] drakxtools-9.2-0.14mdk
On Wed 16 Jul 2003 04:28, David Walser posted as excerpted below: > Adam Williamson wrote: > > How? I use GNOME and Windows - mostly GNOME - every day, and I've never > > had a problem with the buttons being in different places... > > I'm happy for you. I haven't accidentally clicked the wrong button or > anything, but I can certainly see someone doing that. Old habits are hard > to break, and even if you don't go all the way in getting tripped up, it > still has to give you (or some people) some pause. I have. Not in anything where I need to (and do) really pay attention, because it MATTERS, but in little things. In my case, it isn't so much the location as the size of the button that does it, tho location plays a secondary roll to that and I might have clicked the wrong one a time or two based on location as well. The one that gets me most often is a KDE thing, not Gnome, and as I said, it's based on button size. It's the konqueror secure connection dialog, as I use it for online banking, for instance. The button for display certificate attributes or whatever it's labeled, is huge. The button for continue is small. Since by convention the big button is supposed to be the normal "continue flow" button, or they are the same size, I constantly click the display cert button rather than continue. (If things don't check out, there's another dialog anyway, so it's not like you have to check the cert every time for validity -- that's automatic.) They really should make the more info button label shorter, like "more info", or "Display Cert.", or simply "Details", and then make the "Continue" button larger if necessary to make it at least the same size as the details button. **I** "really should" get off my *** and file a KDE usability bug report on this.. (They DID finally fix the signed message background problem in KMail. It used to be white, even if background was set to black by default, meaning font colors were limited to those that could display on white OR dark and still be readable. I prefer console style light on dark rather than paper style dark on light, mainly because I wear contacts and all that white glares and makes it difficult to read. I was just getting ready to file a bug report on it when they fixed it because someone else obviously did.) -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] rpmdrake-2.1-24mdk broken
On Wed 16 Jul 2003 03:36, Robert Fox posted as excerpted below: > rpmdrake-2.1-24mdk barfs when I try to run it: > > [EMAIL PROTECTED] rfox]# rpmdrake ... > Can't locate object method "STRING" via package "Gtk2::GType" (perhaps > you forgot to load "Gtk2::GType"?) at /usr/sbin/rpmdrake line 625. I have the same thing.. because I ignored the "conflicts" warning between some perl-GTK binding library and rpmdrake. There are currently two very similarly named libraries. One is the old style perl inline bindings, the other the new XS bindings. (What that means in English I'm not sure, but.. ) They are incompatible. Currently some packages are updated to the new version, some still require the old version. Thus, not all packages will work no matter what. I chose to take the conflicts and disable rpmdrake as I generally use urpmi anyway, so having rpmdrake isn't a big deal. I figured that way I'd have the new versions, what there were, anyway, installed, and could install the others when they updated. After the upgrade, I attempted rpmdrake out of curiousity, and got the errors you mentioned, so that's the issue. I'm surprised you didn't connect it to the force-install you apparently did, or the warning urpmi gave about it if that's what you used, as I did, with its allow-force option. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Re: [Contrib-Rpm] perl-Gnome2-0.26.cvs.2003.07.04.1-2mdk
On Tue 15 Jul 2003 20:55, Brian J. Murrell posted as excerpted below: > On Thu, 10 Jul 2003 21:02:41 +0200, Thierry Vignaud wrote: > > [Contrib-RPM] > > > > --=-=-= > > Name: perl-Gnome2 Relocations: (not > > relocateable) Version : 0.26.cvs.2003.07.04.1 Vendor: > > MandrakeSoft Release : 2mdk Build Date: Thu > > Jul 10 19:32:16 2003 > > Why does this package not seem to be on either the ftp.sunet.se or > ftp.uninett.no mirrors (yet)? It's absence is holding up some updates in > current cooker... drakconf for one. I just dropped ftp.sunet.se (well, disabled it in the urpmi config file), because something is seriously wrong with it, or was last time I used it several days ago and had been for a number of days. Some rpms simply didn't exist in ANY release on the server, KDE in particular. After comparing listings with another mirror (the rpmfind mirror at rpmfind.speakeasy.net) and realizing how far out of date it was, I added a new one to urpmi (not the rpmfind mirror above as I don't know if it does rsync which I prefer for my urpmi setups), and had nearly a gig of updates to install. After installing part of them, I did an urpmi --auto-select, and it wanted to **REMOVE the latest KDEs and put back old once apparently still listed in the hdlist from sunet, but not on the server so it errored out downloading them. In ordered to get the other mirror working properly without urpmi trying to remove stuff, I had to disable the sunet.se entry. Then using the updated mirror, everything went fine. Anyway, sunet.se seems to be out of contention, at least for cookerites, for now. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Re: Licensing questions
On Wed 09 Jul 2003 02:23, David Walser posted as excerpted below: > MS-shared-source doesn't allow you to recompile the code, so there's no way > to be sure the code they hand you is what's actually behind the binaries > you're running. I'm no expert on it, but I believe that's why some of it you have to go examine on the MS campus, they won't let you examine it elsewhere. I think they allow you to compile it there. Of course, then we have the question of whether the compiler can be trusted. Ideally, you could examine the compiler code, then use it to compile itself, then use that to compile the code you are looking at and verify that it produces an identically sized and hashed binary copy as compared to the official version. How far they let you go down that road, and whether you could trust the machinery they supply in the first place is a good question. However, it's better than nothing, altho I'm sure everyone on Cooker agrees it's a poor substitute for truly open code. However, this is going wide a-field of topicality for this list, so.. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] dosbox in main?
On Sun 06 Jul 2003 06:43, Per Øyvind Karlsen posted as excerpted below: > dosemu used to be in main, but have been dropped (due to compile > problems..?) dosbox is far easier to use and works right out of the box on > several platforms, no need for configuration and it runs alot of dos > programs, maybe this handy package could be included in main?:) BTW.. Anyone else having problems with DosBox now? Attempting to run it from my standard user produces a complaint from mcop, and a segfault: mcop warning: user defined signal handler found for SIG_PIPE, overriding Fatal signal: Segmentation Fault (SDL Parachute Deployed) I can run it as root just fine, but I don't like to do that. FWIW, I have sound disabled in the dosbox.conf, but it apparently STILL wants it, or MCOP shouldn't be complaining. There's apparently no way to ignore it completely, act as if there was no sound there to disable. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Invalid GPG signatures on Mandrake RPMs
On Mon 07 Jul 2003 20:54, Élie Charest posted as excerpted below: > Since about a month, all packages I've installed with URPMI have come with > a bad signature warning. While this is at most an inconvenience (I can > still install the packages) I'm wondering if this is because of a bad > setup, or if indeed the packages are not being signed. This was covered back then on the list, but I guess you missed it.. RPM 4.2 does its own key handling, rather than relying on gpg. Thus, you need to export those Mdk keys in ascii armored format, then import them into RPM. You can check the archives for the specific commands, or it looks like you are familiar with the gpg side already, and the rpm side info can be gleaned from the RPM man page and help output. One cautionary note. Someone mentioned that you need to export each key to its own file from gpg, then import them into rpm, as rpm doesn't work right if put multiple keys into a single file. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] split lists?
On Mon 07 Jul 2003 05:40, Buchan Milne posted as excerpted below: > This has been brought up before, but I wonder if it would be useful to > have focused cooker lists. ... > So, would it be worthwhile to have lists dedicated to: > -server software (apache/samba/ldap/postfix etc) > -KDE > -GNOME > -Other desktop software > -kernel > -admin tools (incl. drakxtools/drakx etc) > > Although a lot of people may end up subscribing to all the lists, Probably add another for non-kernel non-admin-tool core, including networking and connectivity, installation, etc. What of cross-posting issues? What if something deals with a KDE network config/admin tool? It could then be posted to KDE, admin tools, and my suggested core group. If somebody was on all three, they'd get three copies, which would be a bit annoying.. I think this would be a good argument for making it a set of newsgroups, ported to mailing lists for those interested, rather than the current list, or proposed set of lists, ported to news for those that prefer. News has specific provisions for the above scenario, and there'd be only a single copy. Most news clients would track it as such, provided all groups were d/led together, so that there'd be only a single copy, and once it was read on one group, it would show read on all groups. (Said as one that prefers news and has been going to switch to getting the list in that format, but hasn't actually done so yet.. ) -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] postfix: a piece of documentation regarding the chroot
On Mon 07 Jul 2003 07:43, Guillaume Cottenceau posted as excerpted below: > Following bug #3967, I'd like to add a > /usr/share/doc/postfix-2.0.12/MANDRAKE.SPECIFIC.CHROOT_README > file. I'd write something like the following. Please share with > me your wise comments on it. > > -8<--8<--8<--8<--8<- > In Postfix's default configuration of MandrakeSoft's RPM package, > we're running chroot'ed. I think that wording needs a bit of work. The problem is the word ordering, probably due to your attempt to translate your thoughts, but which as written means something a bit different than I think you meant. As written, it appears that Postfix is configuring Mandrake's RPM package, rather than the other way around. I believe you meant to say.. "In MandrakeSoft's RPM package of Postfix, the default configuration is to run chroot'ed." .. That still sounds a bit awkward.. How about.. "MandrakeSoft's package of Postfix by default runs chroot'ed." (Or change "by default" to "in its default configuration") It may be a good idea to mention WHY Mdk chooses to do that, as well.. "MandrakeSoft's package of Postfix for security reasons runs chroot'ed by default." I'd also suggest inserting a URL pointing to a good discussion of the security implications of a chroot, and why it's a good idea in general, quite apart from postfix specifically. Sometimes we just take for granted that people know such info, if they have reason to install such a package. That may or may not be the case, but a sentence or two pointing to a good discussion of the principles involved never hurts and COULD make someone a better admin than they'd be otherwise, especially if they sort of "inherited" the job, with no real training, or are learning as they go and this is their first deployment. Something like (as a footnote for instance) .. For more information on chroots and how they benefit security, see http://whatever.example.com/chroot.htm. B4 U ask, no, I don't have such a URL handy..I'm assuming someone either has a good one handy, or a googlize might be helpful. -- Duncan "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Licensing questions
On Mon 07 Jul 2003 07:25, Buchan Milne posted as excerpted below: > Having the source to software which you distribute is useless if you > cannot fix bugs and distributed the fixed software. Interesting discussion, here. I'm glad to read that it may soon be GPLed.. However, to the specific point addressed by the quote above.. I wouldn't call available source unable to be modified USELESS. Insufficient for Mdk, definitely. Insufficient philosophically to a Software Libre advocate, definitely. Useless, not entirely. At least one specific use (or lack of it in this example) that has been a complaint about MS-ware, for instance, is that it was impossible to security-verify it. MS has addressed that to a large extent with its shared source and government source review programs, thus muting to some extent at least one specific point of the Peruvian documents, that a government would be irresponsible if it chose to use closed source since it is entrusted with a large amount of private data of its citizens, and there was no way to verify that the data remained private, because the source was unavailable. Other points in those documents, including both the data hostage situation and the local economic impact of exporting those $$ vs. keeping them local, certainly remain, but the one point has been to some extent blunted, at minimum. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] cooker - state of play
On Sat 05 Jul 2003 17:12, Stéphane Soucy posted as excerpted below: > I try to put set -x at the start of my /etc/rc.sysinit script and it > stop to freeze!!! > > I don't know why??? Please observe the Cooker list guidelines and refrain from posting in HTML. I am replying to this out of my trash folder, where it was deposited because you posted in HTML, which IMO is only fit for use in mail by spammers and crackers. Some may not see your post at all, if in HTML. (It seems Evolution users have this issue more than most, for some reason. You aren't the first and won't be the last..) Your question?.. I don't know, but I'm guessing it may have something to do with the system not being fully up and ready for such a command at that point. IOW, it may cause BASH to attempt to load something it doesn't yet have access to. It may also have to do with the BASH vs. SH distinction, or some such. Just guesses.. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] more messed up dependencies
On Thu 03 Jul 2003 06:22, Adam Williamson posted as excerpted below: > on urpmi --auto-select this afternoon: > > Some package requested cannot be installed: > drakfirsttime-0.91-13mdk.noarch (due to unsatisfied perl(Request)) I got that too, only here it wanted to install Apache and a mail server to satisfy dependencies! I upgraded the package manually using rpm --nodeps rather than urpmi, and no other issues. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] cooker - state of play
On Sat 05 Jul 2003 14:52, Adam Williamson posted as excerpted below: > But you maybe *do* have the bug. the nvidia module should load if you > have this line in /etc/modules.conf: > > alias /dev/nvidia* nvidia > > but for many of us, it doesn't. We have to load it manually or put it in > /etc/modules. what about you? That's what I thought I said.. However, I attribute it to something else.. the binary only bit of the nvidia module, as I had to force recompile/reinstall of the nvidia module after compiling and switching to 2.4.21, as the nvidia installer otherwise gave me a warning/error about me using a different compiler to compile the module than I had to compile the kernel, tho it was the same one, and I'd just finished compiling the kernel. The only reasonable explanation for that is that the nvidia binary-only component was compiled with a different compiler, which would be expected since I rather doubt they could be using the latest Cooker gcc, when I believe this release (the latest, but..) was out b4 the latest gcc! Thus, I think the problem is the stupid binary-only core, which of necessity HAS to be compiled with something older than the newest gcc, rather than devfsd or some other such thing. I expect the reason it won't load by default now has to do with the compiler differences, tho it will still load if specifically loaded, as it is when loaded from modules or manually. I really wish they'd just release the thing so it could be fully compiled with whatever I happen to be using, already! I doubt I will buy another nvidia card due to all this hassle. (I got this one back b4 I switched to Linux. At the time I was planning to switch, so I verified Linux drivers and that the dual head worked with them, but I didn't know enough to realize what complications nvidia proprietary drivers would cause, nor even that they were different from the nv drivers. I just knew to verify they were there and would work with the card I was looking to purchase.) Of course, one does have a hard time arguing with nvidia's price and wide availability.. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] cooker - state of play
On Fri 04 Jul 2003 19:52, Adam Williamson posted as excerpted below: > still seem to have this devfsd problem that people are experiencing to > various degrees. loop, nvidia, usbmouse and probably some others I don't > know about are not loaded on boot. > > So to boot up I have to pick my kernel, do Alt-SysRq-E when module > dependencies freeze, login to the console, modprobe nvidia and usbmouse, > restart the xfs service and restart the dm service. This is not optimal. > > :) Sounds like that is a bit of an understatement. At least it boots! FWIW.. My system is a bit different. I'm running 2.4.21 self-compiled from kernel.org. As such, I have boot-required modules like reiserfs (on all my partitions except for swap, naturally, and legacy vfat) built-in, so don't need or have an initrd to worry about. That said, with devfsd -30mdk here, no serious issues. I don't have usbmouse (still use ps2, since I have the port and it's less complicated than tracking USB for such a critical input device), but I have nvidia supporting two monitors on my AGP GForce2 (svirge on the PCI supporting a third monitor). I originally didn't load it on boot, but at X start (I boot init 3 by default and start X/KDE from my user login with the kde command from BASH). However, I'm assuming due to the binary portion being compiled with a different gcc, that didn't work after I upgraded to kernel 2.4.21. It does, however, work if I load nvidia from /etc/modules at boot, which I am doing now. I have loopback modulized, but haven't used it recently so don't know whether it works or not. Anyway, while several have said it's a devfsd issue, I'm not sure that's entirely the case, as it doesn't seem to be affecting me here, with a standard kernel.org kernel, and no initrd. If it IS specifically a devfsd issue, the kernel and/or initrd apparently triggers it. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] urpmi --auto-select
On Thu 03 Jul 2003 03:10, Buchan Milne posted as excerpted below: > Levi Ramsey wrote: > > On Wed Jul 02 19:54 -0700, Duncan wrote: > > > > Even if I wasn't making mdk rpms, I'd never do this. Having to use > > either option indicates a bug Please be a bit more careful with your attributions. I didn't write that. What I wrote was snipped, but the attribution wasn't. (For a moment, I was confused, until I noticed the lack of third quote mark the attribution to me at second quote mark implied should be next. I couldn't figure out when I wrote THAT! ) -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] urpmi --auto-select
On Thu 03 Jul 2003 02:17, Levi Ramsey posted as excerpted below: > On Wed Jul 02 19:54 -0700, Duncan wrote: > > I understand those creating mdk rpm packages can't do this, and that's a > > fair portion of the regulars on this list, but here, I always use > > --allow-force and --noclean. > > Even if I wasn't making mdk rpms, I'd never do this. Having to use > either option indicates a bug (especially when its use is required for > an extended period of time... we've had totally broken perl dependencies > because of rpm-4.2 for at least a month now). The thing is.. they aren't TOTALLY broken. Most of that "brokenness" can be fixed with a one-time force-upgrade. That one-time is sort of a "bite-the-bullet" upgrade, because it's a move to a new dependency system. Once it is done, the dependencies, with a few exceptions, then resolve themselves with new versions, because it is again set up in a self-consistent manner. In regard to perl in particular, I'm not sure that an initial force upgrade from what was to the new dependencies system will ever not be necessary. However, once it's done, as I said, the system is again set up for self consistency again. The new system was described at implementation as a bit of serious pain one time, but resolving a low but constant pain with a better approach. That seems to be indeed what happened, as once I forced the single mail perl package, everything else fell into place without issue, because the new package had the provides straight that were handled differently in the old system with resulting conflicts when you tried to move from one to the other. Once the key package was upgraded, the other conflicts resolved themselves, as those on the group said they would. There are a few other temporary conflicts, but they tend to be temporary and fairly minor. These I can see waiting on, but the perl system conflicts.. you might be waiting in vain due to the dependencies system change requiring a single forced upgrade. to resolve the issue during the switch. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker]
On Sat 28 Jun 2003 19:07, Han Boetes posted as excerpted below: > Hi, > > Incase you missed it: >http://www.nzherald.co.nz/storydisplay.cfm?storyID=3509550&thesection=technology&thesubsection=comment&thesecondsubsecti FWIW, everything past the storyID number in the URL is extraneous, so it can be omitted for a shorter link: http://www.nzherald.co.nz/storydisplay.cfm?storyID=3509550 Interesting "Linux Newbie from MS" story. Short and sweet. Not to heavy on detail, but makes the point that Linux (Mandrake) is worth a second look, both because it's free to try, and because of all the free apps that come with it. It'd be interesting to see what he thinks 30, 90, and 180 days in. Will he take to it easily, or reject it at some point as the novelty wears off and he goes back to what is familiar and therefore easy for him? Will he, as I did by 90 days, find Windows is now the one he feels limited in? He did make the point that it's nice to have a "Linux missionary" lighting the way for first install, and that if you are on MS and don't know what Defrag is, Linux may not be for you. I'd add that in that case, neither is MSWormOS, really, as you could be SOL if something goes wrong pretty easily on either, unless you are just a user and someone else is doing the admin, in which case it doesn't make much difference as you can be a simple user on either with little difference in difficulty, at that level. I'd also add that if you are installing MSWormOS and trying to make IT dual boot, you will need an even BETTER missionary helping you with it. The only way MSWormOS is easier to install any more is if you don't HAVE to, which as luck would have it is the case in the majority of instances, but that's beginning to change, slowly, as Linux machines are available off the shelf, now, in a significant number of stores, at least, meaning we've already come a long way in that regard. What gets me is the prediction (not in the article, but since the topic is going this way) that Linux will surpass Mac this year or early next. That's a pretty big step, right there, if you think about it. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] urpmi --auto-select
On Tue 01 Jul 2003 14:53, Gary Walsh posted as excerpted below: > Ryan T. Sammartino <[EMAIL PROTECTED]> writes: > >For the last, oh, two months or so, I have been completely unable to do > >urpmi --auto-select" due to many and various missing or out-of-date > >dependencies. > > I have the same problem, see the thread "Can't use urpmi --auto-select". > My partial solution was to use the --test option which allowed me to > get the list of packages that needed updating. Then I painstakingly > tried to install each one one at a time. This narrowed down the list of > packages that won't install. The main dependency culprits seem to be > gcc and python. Trying to upgrade these two or any packages that depend > on them, results in urpmi wanting to uninstall a large number of > packages. My most annoying problem now is that Mozilla-mail is unable > to open a compose window, so I cannot create mail or respond to received > mail. I have to use the Mozilla installed on my laptop to send mail. > My guess is that an upgrade to XFree86 might be the cause of that > problem, but I don't know. I may have to start over with a complete > reinstall of 9.1 if nothing happens to fix this soon. I understand those creating mdk rpm packages can't do this, and that's a fair portion of the regulars on this list, but here, I always use --allow-force and --noclean. Normally, it then asks if you want to proceed anyway and will then force installation w/o uninstalling anything, but at one point some possibly still uncorrected bugs in the new rpm had it entirely uninstall ALL my KDE. Thus, be careful, but that goes with using Cooker anyway, as it's non-production grade alpha/beta level. The noclean means they stay around in the cache if anything goes wrong and the installation aborts or I answer no to some question or other, so I don't have to red/l them if I try again. Of course, that also means I have to manually clean the cache when everything installs properly. Having the cached packages around after a failed install session also allows me to try each one singly, at least if it gets to the d/l b4 failing. One of the features I've requested is the ability to tell it to go d/l them anyway, with a d/l only option, so if it doesn't get to the d/l, they are still there and I can try that without going to get them manually. Doing the trial and error single package at a time thing usually works, then, for most of them, sometimes all of them, if it was just a particularly complicated dependency that Cooker couldn't figure out, leaving only one or two sub-dependency trees that won't install. By then, I can usually figure out which package is the problem, and more intelligently decide if I want to attempt a force install on it or not. Often, force-installing one will fix the problems on several others even if they didn't seem to be directly related b4. Some weeks ago, this was the case with perl-base IIRC, for example, which once force installed allowed everything else to install without issue. And.. yes, force installing could conceivably create a rather screwed up system, but hey, this is cooker, and I shouldn't be running it on a box that can't afford to be screwed up anyway, so the risk isn't really that bad since I've already chosen to run Cooker on it. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] konqueror crash and knode prob
On Mon 30 Jun 2003 03:26, Michael Scherer posted as excerpted below: > On Sunday 29 June 2003 18:28, Mark Draheim wrote: > > there's something wrong with the latest cooker KDE stuff. This is a > > clean install of todays cooker (well, obviously without the broken > > kernel). > > > > Could someone please confirm that konqueror crashes on this site: > > > > http://www.alternate.de/ > > > > when clicking on "Hardware" in the left frame. Konqueror core dumps > > when I click this. Interestingly, the banner ad that used to be > > embedded in the page is still open in its own window. > > Nothing in the left frame here, so no crash > > kdebase-3.1.2-23mdk > kdelibs-3.1.2-18mdk > kdenetwork-3.1.2-13mdk No crash here either, same reason. x#2 07:19 PM 0bg ~ $ rpmq kdebase kdebase-3.1.2-23mdk x#2 07:20 PM 0bg ~ $ rpmq kdelibs kdelibs-3.1.2-18mdk x#2 07:20 PM 0bg ~ $ rpmq kdenetwork kdenetwork-3.1.2-13mdk x#2 07:20 PM 0bg ~ $ rpmq privoxy privoxy-3.0.2-1mdk I use privoxy as a personal ad-busting and de-crudifying web filter. Images, Java, cookies, and scripting, all off by default. Turning scripting on and reloading the page, it's still blank. Loading images, it's still blank. Viewing frame source indicates there's basically nothing there but an empty body with assorted attribute tags and the default Privoxy onload popup buster scripts.. I see a login. Perhaps the site uses cookies and a login to populate that frame? -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
Re: [Cooker] Can't use urpmi --auto-select
On Mon 23 Jun 2003 08:55, Gary Walsh posted as excerpted below: > It has been a long time since I have been able to use urpmi > --auto-select to upgrade my cooker system. Everytime I try to use it, > it wants to uninstall a lot of packages due to unfulfilled dependencies. > Even using rpmdrake and selecting a few packages at a time is an > exercise in trial an error. This morning, while using rpmdrake, urpmi > wanted to uninstall rpmdrake due to something I selected (I don't know > what). How is it possible to keep a reasonably up to date cooker > install if so many important packages must be uninstalled? Due to the upgrade to RPM 4.2, and some dependency management corrections, a totally smooth upgrade is not so possible right now. It can be done, by forcing some things, if necessary. AFAIK, you will need to force perl itself, for instance, as it will otherwise think it has to uninstall all the modules and other dependencies, but once it is forced, the others upgrade smoothly. There was a similar problem with RPMDrake, but I generally use urpmi anyway and just let it uninstall and haven't reinstalled it, and haven't seen whether the problem was fully resolved or not, on the list. I think you can force it or let it uninstall and then reinstall. There are a couple other such cases as well. It's mainly the growing pains of coping with a new RPM, with its bugs, and at the same time doing some one-time dependency changes that will automate requires that USED to have to be entered manually. IOW, the system isn't entirely stable for upgrade right now, but that's to be expected in the middle of the development cycle, so it's not a big deal. It'll be in-the-main anyway worked out by release candidate time, and should be pretty well worked out by 9.2 gold release. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
