[Cooker] devfsd loops when inserting PCMCIA Flash card in Mandrake 9.1
Dear members,
This involves devfsd, the PCMCIA subsystem and the Mandrake-specific (I
believe) tool "dynamic", so I chose to write here. Please correct me if
you think this is the wrong place.
I use a laptop and Flash card connected through the laptop PCMCIA
connector.
It used to work with Mandrake 8.2 well.
When I inserted a PCMCIA Flash card, nothing bad happened.
I could use transitmount http://transitmount.sf.net/ which basically is
a generic automatic way to mount a newcoming partition-like device in
/mnt/transit/devicename. Very handy for Flash cards, USB keys, photo
camera.
I even modified the /etc/pcmcia/ scripts so that transitmount is called
automatically. So, when I inserted a PCMCIA Flash card it got mounted.
In only had to issue a "cardctl eject" before removing it.
Now I upgraded to Mandrake Linux 9.1 (because there are a lot of
interesting new things. Mostly for me, KDE is becoming usable and
useful.)
Now, when I insert a card, the logs (shown by the very useful xconsole
tool, that should be launched by default on Mandrake Linux, too, unless
maybe at the lowest security level) show that something goes in an
endless loop (complete message at end of mail).
Jun 5 17:25:34 paca kernel: VFS: Disk change detected on device 22:00
Jun 5 17:25:34 paca kernel: /dev/ide/host3/bus0/target0/lun0: p1
Jun 5 17:25:34 paca kernel: devfs_do_symlink(disc0): could not append
to parent, err: -17
(...three same lines repeated and so on...)
I don't know precisely where this happens not what it means. I have
tried to comment the lines in /etc/devfs/conf.d/dynamic.conf:
REGISTER.*/part.* EXECUTE /etc/dynamic/scripts/part.script
add $devpath
UNREGISTER .*/part.* EXECUTE /etc/dynamic/scripts/part.script
del $devpath
But this doesn't change anything.
The workaround I have for now is to kill (or not launch) devfsd. This
way I can do as before. I can read and write the flash card normally. I
issue a cardctl eject (*not* a "service pcmcia stop" as before, this
doesn't unmount the partition nor stops the ide device in the kernel, as
it used to do on Mandrake 8.2).
I thought it would be nice to tell you, so that something can be
corrected. I can experiment a bit if you need some more information.
Thanks for all the fish.
Jun 5 17:25:29 paca cardmgr[28855]: socket 0: ATA/IDE Fixed Disk
Jun 5 17:25:29 paca cardmgr[28855]: executing: 'modprobe ide-cs'
Jun 5 17:25:30 paca kernel: hdg: Flash Card, CFA DISK drive
Jun 5 17:25:30 paca kernel: ide3 at 0x110-0x117,0x11e on irq 5
Jun 5 17:25:30 paca kernel: hdg: task_no_data_intr: status=0x51 {
DriveReady SeekComplete Error }
Jun 5 17:25:30 paca kernel: hdg: task_no_data_intr: error=0x04 {
DriveStatusError }
Jun 5 17:25:30 paca kernel: hdg: 511056 sectors (262 MB) w/0KiB Cache,
CHS=507/16/63
Jun 5 17:25:30 paca kernel: devfs_dealloc_unique_number(): number 0 was
already free
Jun 5 17:25:30 paca kernel: /dev/ide/host3/bus0/target0/lun0: p1
Jun 5 17:25:30 paca kernel: devfs_do_symlink(disc0): could not append
to parent, err: -17
Jun 5 17:25:30 paca kernel: ide_cs: hdg: Vcc = 3.3, Vpp = 0.0
Jun 5 17:25:30 paca cardmgr[28855]: executing: './ide start hdg'
Jun 5 17:25:31 paca kernel: VFS: Disk change detected on device 22:00
Jun 5 17:25:31 paca kernel: /dev/ide/host3/bus0/target0/lun0: p1
Jun 5 17:25:31 paca kernel: devfs_do_symlink(disc0): could not append
to parent, err: -17
Jun 5 17:25:32 paca kernel: VFS: Disk change detected on device 22:00
Jun 5 17:25:32 paca kernel: /dev/ide/host3/bus0/target0/lun0: p1
Jun 5 17:25:32 paca kernel: devfs_do_symlink(disc0): could not append
to parent, err: -17
Jun 5 17:25:32 paca kernel: VFS: Disk change detected on device 22:00
Jun 5 17:25:32 paca kernel: /dev/ide/host3/bus0/target0/lun0: p1
Jun 5 17:25:32 paca kernel: devfs_do_symlink(disc0): could not append
to parent, err: -17
Jun 5 17:25:33 paca kernel: VFS: Disk change detected on device 22:00
Jun 5 17:25:33 paca kernel: /dev/ide/host3/bus0/target0/lun0: p1
Jun 5 17:25:33 paca kernel: devfs_do_symlink(disc0): could not append
to parent, err: -17
Jun 5 17:25:34 paca kernel: VFS: Disk change detected on device 22:00
Jun 5 17:25:34 paca kernel: /dev/ide/host3/bus0/target0/lun0: p1
Jun 5 17:25:34 paca kernel: devfs_do_symlink(disc0): could not append
to parent, err: -17
Jun 5 17:25:34 paca kernel: VFS: Disk change detected on device 22:00
Jun 5 17:25:34 paca kernel: /dev/ide/host3/bus0/target0/lun0: p1
Jun 5 17:25:34 paca kernel: devfs_do_symlink(disc0): could not append
to parent, err: -17
Jun 5 17:25:35 paca kernel: VFS: Disk change detected on device 22:00
Jun 5 17:25:35 paca kernel: /dev/ide/host3/bus0/target0/lun0: p1
Jun 5 17:25:35 paca kernel: devfs_do_symlink(disc0): could not append
to parent, err: -17
Jun 5 17:25:36 paca kernel: VFS: Disk change detected on device 22:00
[Cooker] Mandrake Update: offer uninstall option
Hello, It often happens that during a Mandrake Update I discover that one program installed on my system is actually unneeded. Upgrading it is useless, but if it is a security threat it should not stay there. It may be a good idea to have in the Mandrake Update UI an option that means "don't upgrade this package but rather uninstall it". So there are three states: upgrade/don't upgrade/uninstall This would be good for security and handy. Especially, small sites (small enterprises for instance) with slow connection to the net would sometimes avoid long and useless downloads to upgrade unneeded software. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
Re: [Cooker] Re: Re: Re: RFC: Can we eliminate all forms of modifying/usr for 9.*/10.0?
On 9 Oct 2002, Guillaume Cottenceau wrote: > Yes, though if the flexibility costs so much, It doesn't cost that much. One hard prerequisite is to think it right. But Mandrake doesn't have to do this job themselves: that's what the FHS is for. Standards make things clear. Following them is not as hard as designing them. > it may become questionable whether we do it or we do other things > which may be more useful to a larger number of people. I see your > problem as something valuable but rather a "niche" than something > really useful to a large number of people. Linux is used in a lot of universities, with small or large networks of client machines. Sometimes, a cascaded system exists, where central servers provide common apps, and local admins can tune local things. /usr exists for that. The Unix hierarchy has been doing this for ages. Every package that breaks this is flawed. Big Cybercafés sometime use this, too. Having /usr mounted via NFS make it much easier to maintain and secure... if it doesn't break all packages. How can you tell newbie sysadmins that files in /usr are meant to be frozen, variable files go to /var, when kscd puts its growing stuff inside /usr ... Besides this, the lack of unattended package upgrade facility for clusters of machines, and the flakey distribution upgrade that makes the sysadmins prefer install from scratch instead, currently limit Mandrake to a lonely desktop machine -- or a collection of lonely desktop machines, until you roll your own local hack to cope with this. The solution we have here is our homemade package that installs and configures a list of things. (To my knowledge, MandrakeUpdateRobot didn't make the reliable unattended daily update we expected, but sorry, I've not tried 9.0 yet, things might have changed. As for the upgrade, from 8.1 to 8.2 did break many things when we tried, too many to fix. If things have gone better with 9.0, tell me.) I have other ideas for alternative solutions, but I'll tell in a different mail. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
[Cooker] Faster boot scripts: case for serel
Hello everyone, It seems that the boot process could be accelerated somehow by using serel (http://fastboot.org). The basic idea is: you can run in parallel the initialization of some services, especially those who have to wait for something external. The prerequisite: you have to describe dependencies between services. Parallel build using make are really useful. Similarly, several services rely on other, and we can start network first, others while it waits, instead of starting one by one and wait several seconds with the machine completely idle while waiting in sequence for the startup of all services. It was mentioned very briefly, but not discussed on Cooker list, Google returns nothing relevant while searching "cooker serel", and the RPMS in 9.0 don't mention it, so I can assume that it's not used in 9.0 even if I haven't tested 9.0 yet. I lack time for this in this period. Would someone like to test drive serel http://www.fastboot.org/ on Mandrake ? If, as it says, it accelerates the boot process, while giving a nice visual feedback, it may be nice. One may argue that it is overkill because it needs a description of the boot processes dependencies, but maybe it's not overkill. After all, make needs a description of dependencies, and we all use it. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
[Cooker] Smart network switching, both at boot time and live.
Hello, On 22 august, [EMAIL PROTECTED] wrote: > I'm using the MDK 8.2 on my laptop (Inspiron 8200), where I'm using > DHCP. But when I start my laptop outside of my network, the eth0 > activation make a bunch of retry to find a DHCP server before cancelling > ( Time-out after 1 minute or something like that). Is it possible to > find a fix for this? Detect the cable maybe ? Start the dhcp client in > background ? Shorter Time-out ? First, there's an mii module in kernel 2.4 (not for all NIC yet, but the most common), that can detect if a cable is properly plugged in on a live ethernet link, or not. It can be used to see if it's worthy to wait at all for a dhcp (or other) reply. Note that there are tools (Debian has laptop-net) that can automatically recognize on which network we are (from MAC adresses of packets passing by) and use a known IP, or revert to DHCP on an unknown network. This is a must for people who move their laptop between two or more networks (or Wi-fi). This is what Mandrake needs to become smarter about the change or lack of network at boot time, and even when the machine is already up, too. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
[Cooker] Columbus: *real* automatic net switching for laptops
Hello, Mandrake aims at being easy to use. There is a spot that needs improving, and it is important for laptop users. It would be nice to unplug your laptop at work, go home, plug your laptop to the local net, and have it reconfigure itself correctly. Several programs exist that use arp requests to recognize the network, like "divine" http://www.fefe.de/divine/ or "intuitively" http://www.add.no/~tollef/intuitively/ . Some of them include a fallback to plain dhcp if the situation is unknown. This is very nice when arriving at a new place (at a customer's site, etc...). This is good. Why is none included in Mandrake ? (Because users should contribute. Right.) But read on, better can be done ! Some of us know that Kernel 2.4 has the possibility, through the "MII" feature, of detecting when you plug/unplug a network card (currently, not all card driver support it, but the most common cards on laptops do support). This is GREAT ! This opens the possibility of having the roaming scenario (home<->work<->other place), but have the reconfiguration occur automatically, without any manual (root) intervention, selection menu, etc... People target by Mandrake need this feature. It is absent. Meanwhile, Debian has laptop-net, which looks quite good. http://www.swiss.ai.mit.edu/projects/omnibook/documentation/laptop-net.html http://packages.debian.org/stable/admin/laptop-net.html Columbus is similar, but redhat-oriented, so should work on Mandrake. http://freshmeat.net/projects/columbus/ Mandrake has to do something. I might try this if I have time. If anyone can work this out, this would be a killer feature to have, (and a be-killed feature, not to have ;-). -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
Re: [Cooker] feature request - multiple X sessions through kdm/gdm
On 20 Aug 2002, SI Reasoning wrote: > I know it already exists in Linux. What I liked about XP was how it was > implemented. GDM allows you to pre-open several X sessions at once, > regardless of whether they are used. You would also have to know the > keystrokes to get to each x session and any session that did not have a > quick screensaver with password enabled could be accessed by anyone else > once logged into. > > What I was bringing up was the idea of making it simple and intuitive, > with listings on the unified menu of who is logged into each X session > and the ability to click on that name to switch to that x-session (with > the proper password). Also make starting up new X-sessions on demand and > the ability to kill any extra X-sessions when a user logs out. I completely agree with you. The important thing here is that with XP it is so easy to find and understand that everybody know how to use it at first try. Whereas, no one ever thinks about going into Start -> Boot and Init -> New login with GDM, and even those who find it by chance cannot ever guess what it means. This is a typical situation where Linux has more features, but it inaccessible to most people, and more complicated to use, even for simple situations. This is a job for Mandrake to make it easy with Linux, too, at least in common situations. Perhaps Mandrake should design a small "switch X user" application (needs some root privilege) which would appear in the first level of the Mandrake menu (which is windowmanager-independent, thanks for this very important feature -- where does it come from originally ? ;). It would offer two explicit choices -"log in as a different user without interrupting current session" -"switch back to an already logged session" and a list of user icons have an "advanced" tab that trigger displaying screen depths with icons -select screen depth: [*]default []8bpp []16bpp []24bpp []32bpp and perhaps (in a future version) -freeze current user apps [yes/no] (why ? because some apps might be running, take resources for nothing, which prevents them from being simply swapped out. What about remote apps, well the X protocol is known to do a lot of things, it must already implement some kind of xon/xoff-like feature "i'm asleep for a while") This would: -as the user running the current session, lock the screen with the screensaver the user is currently using (ask the X server about the presence of a client, NOT the local process table because the screensaver client might be remote, or do things like "xscreensaver-command -lock" which does the right thing), or launch a simple one if there is no one running -as root, launch a new X server, that queries GDM/KDM/whatever; which does the rest of the job in case of a new session -OR in case we switch back to an existing session, locate the correct virtual terminal and perform a "chvt" (or directly the correct ioctl). (and perhaps wake up the X server that might have gone to sleep or even switch of the monitor) There are some issues in special cases (pure X terminal with remote *dm, etc...) and GDM/KDM has to be properly configured to accept new connections. Perhaps this is actually all a job for the display manager, not for a new, standalone app. Also, I agree with answer by MandrakeSoft people that it might be better to have all this handled by one single X server, not launching several ones (too bad for the different screen depths). Conclusion: If the existing but beginner-unusable feature is invisible, and no one puts it forward, this will never change. If you popularize this feature, things will change. The basic argument is: Unix and Linux are multi-user systems. A complete multi-user environment should make easy for people to share a common console without reading the Console-Howto. (Also, same thing for changing screen depth...) There are some other small issues but this mail is too long already. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
[Cooker] "Tip of the context" for educating the user: numerous omnipresentlinks to docs, what might make people stick to Linux or not.
For a few years, I've been doing some Linux advocacy to a number of people around me, installing RedHat, then Mandrake (when Mandrake started existence) on their machines, talking with them. The mileage varied. A lot of work has been done to have Linux easier to use. The desktop gains maturity (though big holes still exist). Administration tools progress (though it hurts everybody that Mandrake tools don't benefit some progress made by Debian years ago, and vice versa). But some people that looked interested in Linux at first sight told me later "I've abandoned. I can't do what I want. I'm stuck. I don't know how to search and learn what I want to do". Willing to take care of the house so that the user doesn't have to do housecleaning is a good intention. But if you don't often show the user opportunites to educate himself it will remain difficult and time-consuming. I finally managed to grasp the thing and know how to do what I want, but I had to eat and drink and swim in and drown into a lot of random docs, until I learned enough to do what I want. Not everybody wants to devote so much time for it. Yet, it would be a huge pain to think that because a system has GUIs that should be simple, then it couldn't satisfy power users, and it couldn't give hints to educate users. In a nutshell: don't be confused between "not assuming that the user knows everything" and "assuming that the user knows nothing" or, worse "assuming that the user doesn't want to knows anything" (which may sometimes happen, but if you follow the first case you won't conflict with the two others). If you don't assume more than you should, you shouldn't hurt anyone. Whereas if you assume that the user knows nothing and doesn't want to knows anything you frustrate a lot of people (especially on this list). More generally, I think that an "educating" aspect should be more widespread in Linux, even from the installation. (Debian does that to some extent in some context IIRC.) Very few people look at on-line manuals, because they don't know how and where to look, and it's too long anyway. There have been attemps to provide unified way to access and search in various docs (gnome-help-browser, xman, and other old tools by RedHat which name I forgot), but these don't solve the main issue. The "tip of the day" sometimes helps, but independently of what I mean here, mainly because it happends on a fixed place, and its subject is random. There are plenty of opportunities to create little "Where to know more..." features (in the tools, in the desktop, etc...) that would point you to a precise spot in a documentation (either done by Mandrake, like a relevant paragraph of an online manual, or external, like a paragraph in a Howto). Of course, they shouldn't be annoying, so popups (and nasty paper clips) should be avoided. Instead, a small, unique, standardized icon, like an incandescent lamp (or a book, but it suggests long reading, which is contrary to my point), should appear next to many items, in many places. Then the user knows (even if he doesn't click at once on them) that there are informations to help him when he wants to know more. A few quick examples: in logdrake GUI, one "I want to know more" button would give a few lines explaining that the log files are in /var/log and that more is to be found in http://www.tldp.org/LDP/sag/x595.html or http://www.pathname.com/fhs/2.2/fhs-5.10.html in mkbootdisk GUI, one "I want to know more" button would give a few links like you can find here: http://www.tldp.org/HOWTO/Bootdisk-HOWTO/x1440.html in rpmdrake GUI, tips that say "you can also access similar functionality by using urpmi or, at a lower level, rpm" in "connection sharing", say that other firewall applications exist, that allow greater flexibility, like Bastille. I should add some better examples. One application would have many of such hints. Got my point, anyway ? For example, what if each and every gimp "tip of the day" entry could be hidden behind an icon in the program. When in the "layers" dialog, the icon would serve all tips relevant to the layers in an image, not the one about drawing straight lines. Think "contextual tip of the day", if you like. It is very important that those little informations points are accessible next to the items they correspond to. I'm not telling you that Mandrake should write some more docs, but rather that people should find easily the doc they need, even if they didn't imagine that the doc existed. This would be a big plus, since it would allow an easier learning curve for not bright nor dumb but unexperienced users who would like to know, and not get in the way of those who don't want to know. To prove the validity of the approach: Have you ever noticed how the "help" buttons for the kernel building UI (make xconfig) are efficient ? In 10 lines, a "help" item about a choice in the kernel always manages to tell you : what it is about, a few hints about how to make your deci
Interface issues (Re: [Cooker] new rpmdrake problems)
On 19 Aug 2002, Guillaume Cottenceau wrote: > > [4] if the checkbox could be at the left of the name instead of the > > right, you'd see it even if the widest package name was wider than > > the sub-window listing packages. > > There are hardcoded sizes so that the box must never disappear. For heaven's sake, I hope they are not coded in pixel units, but in a character height/width unit. There are some nice pieces of software that really look pityful (windows too small and non-resizable, clobbered text in boxes and buttons, etc) just because they are coded in pixel unit and you happen to have a hi-res screen (say, 1400x1050 on 15", like Dell laptops) so choose bigger fonts in Gnome (KDE does it automatically depending on the dpi returned by X). Please do think about it. > > If you don't do this, *please* make it clearer which box goes with > > which item - they are too far apart for me to be certain I'm > > clicking on the right thing without selecting one. Also note that if > > I make a selection, the blue is dark enough that I can't see the > > checkbox any more, and yet I also can't easily read the white text. > > A pastel blue or yellow would probably be better. > > Hum, are you colourblind or something? Even if he isn't, some others might be. I prefer the checkbox on the left, you're sure it's close to the item even if it's short. > > The URL should be copy/pastable text! > > This seems minor to me :-). IMHO, all text in all windows of a windowing system should be copy/pastable. This would mean, incidentally, that it's not up to the applications to take care of it. Ever been frustrated, not to be able to copy/paste an error message in a dialog box to mail it to a maintainer ? > > It looks like it installed the packages and then just went away?!?!?!?!? > > did it install all of them? how do I tell? What if it uninstalled some > > packages in order to satisfy dependencies? What if it installed extra > > packages? > > Like previous "grpmi" version, when there is no problem there is > nothing reported. I think that a report should always be generated. Something like: "The packages xxx, xxx, xxx were installed. For their proper operation, is was needed to install: yyy yyy and to upgrade or remove: zzz zzz [Ok]" Even if most of the time it shrinks down to: "The package foo was installed. No additional package was needed for proper operation. No previously installed package conflicted. [Ok]" I liked the summary in the previous versions of rpmdrake, though having to click on "cancel" to confirm was a bad UI choice. The report "educates" the newbie by telling him that this program actually does a goob job behind the scene. When you ask for a beer at a bar, you do expect the barman to give you and say "here you are, sir" or something, not disappearing while you find the beer in front of you. I know that precisely, traditional Unix programs follow the "no problem, no report", which is very good because those can be scripted, etc... but since rpmdrake is a end-newbie-user-interface, it's good to produce a report. It's clearer for the user, which becomes more confident in the tool. > With current rpmdrake version, after installation you're back to > the main rpmdrake window so it might be less awkwark. "Will you take anything, beside your beer ?" We do agree ;-) -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
[Cooker] rpmdrake feature to regain, turns into a search engine
In relation to the recent rant about the new rpmdrake... * One more disappearing regreted feature: In previous releases (7.1 I think) there was a primitive rpmdrake tool, that allowed an interesting feature, though it was not intended by the developper, and disappeared in the 8.x. Imagine you were looking for, say, an xfig replacement. You would search for xfig. In 7.1 the search engine highlighted xfig *in its category*. Then, you just had to look at xfig's neighbours in the category to find similar programs. In 8.x the same search returns only programs that contains "xfig" in a separate list. (This list is good because you can select several packages at once.) But you lost the ability to browse the category. Still, the categories exist (they existed in RedHat 4 and probably even before), but you can't take advantage of them in the 8.x rpmdrake. * When this becomes a suggestion of improvement: To continue with the xfig example, I know that you can look for "vector drawing" or the like, but sometimes you know a program that is similar to the one you're looking for, but you don't know what keywords to use. (Or the keyword is too vague, like "network" of "font" so you have tons of irrelevant results.) The improvement could take the form of a button (or contextual menu) that says "jump to the category where this package belongs". So, you search "xfig". The xfig package is selected. You click "jump to category" and voilà, you have sodipodi. (There may be some more relevant examples). * And in your wildest dreams: The essence of this idea is to take advantage of the neighbourhood relationship between packages, instead of merely a keyword-based matching. This is already what you do in a file manager when you use sort-by-name/date/size. The idea is to add to the "sort" criteria more similarity criteria: function (vector drawing), environment (KDE/Gnome/...), dependencies (qt,xml,...) to jump and/or filter. In a dream you could imagine an interface like in http://kartoo.com/ There are researches about "self-organized maps" (SOM) where some may take inspiration. * Conclusion When the number of packages in a distribution becomes very large, what you actually need is a package search engine. And a good search engine tries hard to take all available information to focus on relevant answers and provide easy ways to navigate and refine the query. That's what Google does. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
Maybe already irrelevant, but... was: Re: [Cooker] Ugly andnonergonomic rpmdrake !!!
I agree with David Grant's five points. But read on after the quote. On Mon, 12 Aug 2002, David Grant wrote: > I sort of agree, although my criticism of the new version is not so > harsh. Simplicity is always better, although not at the sacrifice of > necessary features. My main points: > > 1) The ability to search through titles or descriptions should be > brought back > 2) All the facilities of rpmdrake should be accessible from one GUI, not > 4 (!!!) menu entries! > 3) When installing/removing packages, once a certain package is > selected, it should be shown in a list, so that the user knows which > packages are currently selected for installation/removal. > 4) It should be possible to remove and install packages simultaneously, > just like in the old rpmdrake. > 5) BUG: rpmdrake closes right away after installing a package. Expected > behaviour: it should stay open, in case you want to install some more. > > Please lets add on to this list, telling developers exactly what we > liked about the old rpmdrake, and provide developers with some clear and > precise things to improve upon in the new one. I haven't tried this latest rpmdrake, so what I said may be already obsolete: 6) The whole rpmdrake and package installation is so slooww. Not only the rpmdrake startup time (a correct usage of a database doesn't need that). Why does it have to "build interface" ? etc... (This reminds me of the HP48: it could be very very fast but the HP developpers continuously added more and more functions on top of much too high-level (and slow) ones whereas there existed some faster, high-level-enough and very relevant features to use first. 7) I hope the ever annoying useless modal window that wiggle left and right has disappeared. (You know, the one without decoration or cancel button, that brings no information other than "I'm a software for newbies, and no, I've not crashed yet".) Such a window is absolutely useless. Its main feature is eating bandwidth, which definitely forbids you from using rpmdrake on a remote display if the hosts are not on the same fast local network. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
Re: [Cooker] Internet Connection Sharing on one interface card
On Fri, 19 Jul 2002, Ramon Casha wrote: > The Internet Connection Sharing utility in Mandrake Control Centre (8.2) does > not list eth0 or any aliases. Apparently there is an assumption that the > internet connection won't be on the same interface card. However, this can > easily be the case with, for instance, ADSL connections. My point here is: with most home<->internet connection services, your ISP doesn't want you to share your connection with other machines. IMHO this is a bad policy: technically, sharing your connection doesn't steal bandwidth to anyone. But if the contract with your ISP says that you won't share it and you do, you break the rules. Furthermore, using only one ethernet card on your gateway PC may have some side effects. > I have successfully set up my ADSL connection, using eth0 with the address > 10.0.0.10 making the connection to the modem, and eth0:0 with the address > 192.168.0.1 set up as the connection-sharing interface. I had to twist the > configuration script's arms a little to make it accept eth0:0 but it worked. > Perhaps this limitation can be removed from the script -- unless there was a > good reason for its inclusion that is. I presume you hook all your machines, including the ADSL device, on a common hub. Diagram: local machines including gateway PC <=> hub <->ADSL<->internet Sharing a connection this way works, but is somewhat dirty. Let's assume you do it this way. Technically, there's nothing wrong about having different logical subnets on one physical ethernet link, as long as devices really comply with ethernet rules and RFCs. But are you sure that the ADSL gateway handles properly packets with private IP ? Does it really respect ethernet specifications (e.g. ignore all packets not specifically sent to it) ? Maybe it sends to the other side of the ADSL connection any packets it receives from the ethernet wire ? Why ask ? Well, the ADSL device you have is supposed to handle the case where you link it directly to only one machine. Any other setup may have unexpected results. No one told you that it was configured to be RFCs conformant. It might even be programmed to report any unregular usage to the ISP. What about broadcast packets send from a local machine to the local (private) broadcast destination ? Accorging to ethernet rules, the gateway will receive them (they're broadcast). Perhaps the ADSL gateway doesn't know they're private, and it sends them to the internet, eating your upload bandwidth (usually 128kbps on ADSL). According to RFCs, it shouldn't, but your ISP never claimed anything about that case. Think about what may happen if you have some windows machine on the local net, or some cups server or clients. They like to broadcast information. The clean way: If your home PC has two ethernet cards, and you link it the regular way: local machines <=> hub <->eth1 gateway PC eth0<->ADSL<->internet then as far as the ADSL device and your ISP are concerned, all hypotheses are valid. You can't disturb the ADSL device or let private packets go out. Technically you plug only one PC on the ADSL devices, like your contract says.0 And a bonus: your gateway PC can act as a real, physical firewall (with Bastille for example, for an easy start). A second ethernet card is cheap (less than 15 euros). You can afford it. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
more details (Re: [Cooker] Failure on 'setup' update)
On Thu, 11 Jul 2002, Pascal Terjan wrote: > warning: /etc/group created as /etc/group.rpmnew > warning: /etc/passwd created as /etc/passwd.rpmnew > setup ## > /var/tmp/rpm-tmp.17599: line 1: 3517 Segmentation fault /usr/sbin/update-passwd Same thing, but more details to help you reproduce the problem. This is on Mandrake 8.2 . Upgrading openssh wants to create a 'sshd' user (see changelog). Upgrading setup after that triggers the problem. [root@h rpms]# update-passwd -v Reading passwd from /usr/share/base-passwd/passwd.master Reading group from /usr/share/base-passwd/group.master Reading passwd from /etc/passwd Reading shadow from /etc/shadow Reading group from /etc/group Removing user "sshd" (94) Erreur de segmentation (core dumped) Re-running the program yields the same output. An affected system will fail to install properly all packages which are dependant on update-passwd. This is serious. Notice that the update-passwd binary is itself in the setup package. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/
[Cooker] Upgrade failed: X error : BadWindow
I just burned a 8.2rc1 from a mirror. I checked the md5 of the ISO using md5sum -c -> OK. I boot it on a laptop that has mdk8.1 I chose french, upgrade recommended, and ... window no longer refresh (only the colored background remains, and the "Mandrake Linux 8.2" bitmap on top of screen). X cursor stays with the "watch" icon (I can move it). Nothing more. Here's the log on tts/1: Entering step `Choose your language' Entering step `Select installation class' Entering step `Hard drive detection' Entering step `Setup filesystems' Entering step `Configure mouse' Entering step `Choose your keyboard' aewm: X error (0x8003e8): BadWindow I reboot and try again. The problem disappears. (Upgrade is in progress now). Maybe a race condition somewhere in the installer ? If it happened to me, it may happen to other people in the future :-/ (I guess there are more urgent issues anyway ?) -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/ "What difference does it make to the dead, the orphans, and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty and democracy?" -- Ghandi
closed/fixed (Re: [Cooker] devfs problems and a hint)
Since recent discussions stressed the importance of not letting open issues unanswered, here I go. rc1 (and, I guess, the final version) seem to add a "devfs=mount" option to the kernel, via the bootloader. (At least, on the laptop I've tried here.) Also, please don't release too many final versions while people only have time to download one or two candidate isos. ;-) (Ok, the right thing to do is to maintain a local cooker repository, but I have to get started first.) On Tue, 19 Mar 2002, Stephane Gourichon wrote: > Hello, > > I've had some problems with beta4, but they may still exist in rc1. > > I've installed a vanilla beta3, then upgraded to beta 4. Standard kernel > included in the ISO, no special modifications (expect switching from oss > to alsa sound driver). > > At beginning it worked ok. > Then I noticed some things didn't work. > I saw that devfsd was no more launched at boot ! > > After investigating, adding "devfs=mount" explicitely in the kernel > command line (via grub/lilo) solved the problem. > > It's strange, because I never had to do this before. > (I've kept copy of the /etc in my old setups and compared) > > Maybe this can be a hint to someone that has devfs problems ? -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/ "What difference does it make to the dead, the orphans, and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty and democracy?" -- Ghandi
[Cooker] devfs problems and a hint
Hello, I've had some problems with beta4, but they may still exist in rc1. I've installed a vanilla beta3, then upgraded to beta 4. Standard kernel included in the ISO, no special modifications (expect switching from oss to alsa sound driver). At beginning it worked ok. Then I noticed some things didn't work. I saw that devfsd was no more launched at boot ! After investigating, adding "devfs=mount" explicitely in the kernel command line (via grub/lilo) solved the problem. It's strange, because I never had to do this before. (I've kept copy of the /etc in my old setups and compared) Maybe this can be a hint to someone that has devfs problems ? -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/ "What difference does it make to the dead, the orphans, and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty and democracy?" -- Ghandi
Re: [Cooker] [OT ?] keeping device names constant for removeabledrives
On 16 Mar 2002, Byron Poland wrote: > I'm not sure if this is the best place to post this but, I think it is a > usability issue. > > I now have 3 external removable storage devices, 1 acomdata 80 gig > firewire drive (dev1), 1 firewire enclosure with a 30gig drive in it > (dev2), and 1 usb smartmedia card reader (dev3). I have all 3 working > fine with the latest cooker + some firewire cvs drivers (so the acomdata > drive gets recognized). > > Problem: when ever I plug a device in it become sda, and then add more > they becoe sdb,c.. > > say I have all 3 devices plugged in, then I have sda, sdb, and sdc. > > problem is dev3 is fat (smartmedia card) dev1 has ext3 and fat32 > partitions on it and dev2 has just one ext3 partition on it. > > how do I set up fstab and I guess devfs so that no mater how many > devices I have plugged in, and no matter what order they were plugged > in, all I have to do is type: > > mount /mnt/smartmedia -> dev3 mounts > mount /mnt/fire1 -> dev1 part1 mounts > mount /mnt/fire2 -> dev1 part2 mounts > mount /mnt/fire3 -> dev2 part1 mounts I've designed a program for this purpose. The idea is to put a label on your partitions once, and then they get mounted according to their volume label every time. In a nutshell: e2label /dev/sda1 MyExt3Drive or mount /dev/sda2 /mnt/tmp echo "MyVolumeLabel" >/mnt/tmp/volname umount /dev/sd* and then, automically every time, they get mounted (with some proper sanity checking, fsck, etc...) in: /mnt/transit/MyExt3Drive /mnt/transit/MyVolumeLabel whatever the order of plugging in. Visit http://amphi-gouri.org/transitmount/ or http://transitmount.sourceforge.net/ The current version is beta and only launched at boot time. But you can launch it whenever you want (i.e. just after plugging firewire or USB). It would be nice if the "hotplug" package would call "/usr/sbin/transitmount" automatically. I've no such removable devices, only IDE disks that need powering off the machine, so I'm waiting for feedback from users for ways to improve it. See you soon. Thanks for any feedback. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr/ - philo du dimanche http://amphi-gouri.org/ "What difference does it make to the dead, the orphans, and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty and democracy?" -- Ghandi
[Cooker] msec: excessive assumptions in networked environment, and solution
Beware of excessive assumptions in programs. Remember that Ariane 501 rocket exploded because programmers assumed some circumstances without first verifying that they are true... The new msec package fiddles quite a lot about file permissions, and assumes "for certain" things that are common but not guaranteed. For example: *it assumes that every entry in /home is always the homedir of a user. While this is true in a vanilla lonely Mandrake system freshly installed from scratch, it is wrong in many places. When the station is a node in a cluster of machines sharing users, userdirs are often mounted from other places, like: /home/teamname/username. *also, msec fiddles with kdm display of users icons. kfm offers at least: "none", "selected", or "all". msec forces it to "all" or "none". In our case, each station is in a team, display about 10 users, not the 100+ users of the whole lab! Networked pools of machine are the traditional setup for Unix systems. Please be careful, while trying to extend Linux on the home market, not to lose the original niche. ... and it looks like msec comes quite often back to force changes against the system administrator will. This has the potential of getting many systems administrators upset. *** Solution (well, idea at least) There could be some interface à la kudzu that spots each change: "msec has noticed that the permission of /home/team/ was changed from 711/drwx--x--x to 755/drwxr-xr-x. What should msec do ? * change it back to 711/drwx--x--x * let 755/drwx--x--x be the new normal value to enforce * from now on, don't check /home/team/ permissions again Remember this situation and do not ask again [y/N]: _" My two euro-cents for today. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr - philo du dimanche http://amphi-gouri.org/ "Bonjour, je ne suis qu'une phrase entre guillemets dans une signature, mais si vous me recopiez dans votre signature automatique d'e-mail, alors je pourrai continuer à me reproduire comme un virus. Merci !"
[Cooker] Automatic mount (cf ".mount in each filesystem")
I have designed a tool that I think will be useful to some people. It's named "transitmount". I have a "data" disk that I often move from one computer to another. I was tired to mount it as root each time, so I designed a program that automatically checks at boot if some partitions are not mentioned in fstab, and mount them to a convenient place. For example, I labeled an ext2 partition like this: e2label /dev/hdc1 MyLabel And whenever I insert the disk into a (powered-off) machine with transitmount installed, it gets mounted automatically under "/mnt/transit/MyLabel" on boot-up. If no label is available, the directory name is based on the device name (/mnt/transit/hdc1, or /mnt/transit/ide0_host0_blahblahblah in devfs-based systems). Since labels are not supported on all filesystem types, you can also: cd /mnt/transit/ide0_blahblah_ugly_name echo MyOtherLabel > volname It deals nicely with devfs/non-devfs systems, follows symlinks, performs a fsck to make sure the filesystem is clean, etc... I haven't offered it to cooker, yet, because I only recently made a RPM and it's not (yet) Mandrake compliant. Maybe it's time to do it. Of course, feedback and bug reports are welcome. Current version is 0.5, available from: http://amphi-gouri.org/transitmount/ or http://freshmeat.net/projects/transitmount or http://sf.net/projects/transitmount/ Current version needs at least kernel 2.2 and perl 5.6. It mainly relies on the kernel /proc/partition feature. It might be interesting to test it with PCMCIA IDE controller, which allow hot-plug, and those digital cameras that behave like a SCSI disk through a USB connection. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr - philo du dimanche http://amphi-gouri.org/ "Bonjour, je ne suis qu'une phrase entre guillemets dans une signature, mais si vous me recopiez dans votre signature automatique d'e-mail, alors je pourrai continuer à me reproduire comme un virus. Merci !"
labels and mountpoint (Re: [Cooker] .mount in each filesystem)
On 6 Mar 2002, Guillaume Cottenceau wrote: > Keld Jørn Simonsen <[EMAIL PROTECTED]> writes: > > > Wish: I have a number of file systems, and I would like > > the install program to find them automatically. DrakX > > already does so for standard partitions like / /home > > /var etc. I thought if there was in the root of > > each file system a .mount file that just contained the path > > on which to mount it would save me grief and maybe 10 minutes > > everytime I install. Just an idea. > > Is ".mount" just your guess/invention or something which is > supposed to be a standard? There is a more standard way: the filesystem volume label. the -L option of mke2fs or tune2fs allows a 16 character-long volume label. ext2 and relatives also have a not-well-enough-known field, the "last-mounted-directory", which is I guess an excellent candidate for this purpose. See in mke2fs or tune2fs : [-L volume-label] [-M last-mounted-directory] We could consider that on modification of the fstab, the configuration tools set the "last-mounted-directory" of the filesystems to the directory where it is supposed to be mounted ? This would give a precious hint for a smarter installer (and for some rescue/upgrade tools, also, in case /etc/fstab is lost...) See my next message, too (regarding Automatic mount). -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr - philo du dimanche http://amphi-gouri.org/ "Bonjour, je ne suis qu'une phrase entre guillemets dans une signature, mais si vous me recopiez dans votre signature automatique d'e-mail, alors je pourrai continuer à me reproduire comme un virus. Merci !"
Checking integrity of ISOs (Re: [Cooker] Problems installing 8.2beta 4)
On 5 Mar 2002, richard bown wrote: > Mike try downloading from another mirror, I found on the swedish site > cello.se cd 2 on beta 3 must have been corrupted, the file size was > correct on download, but during a burn it always stopped about half way > through the write cycle,. > A second download from the same site gave the same, downloading from > another site cured it...maybe worth a try?? In this kind of situation, download the "md5sums" files in the same directory as the ISOs, and use the "md5sum" utility to check that the ISO you've downloaded are correct bit for bit. Then: if the md5sums correspond, it's your burner/system fault if they can't burn it, and you'll save time and bandwitdh avoiding a useless transfer again. Just burn it at a lower speed and/or with simulated burning. If the md5sums are wrong, the problem was in the transfer and/or is in the mirror. You may then want to report the problem to the ftp server maintainer. Bye -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr - philo du dimanche http://amphi-gouri.org/ "Bonjour, je ne suis qu'une phrase entre guillemets dans une signature, mais si vous me recopiez dans votre signature automatique d'e-mail, alors je pourrai continuer à me reproduire comme un virus. Merci !"
[Cooker] UTF8 and changing mind about i18n/LANG
Hello, During install of 8.2 beta 3 I chose French (UTF-8) as default locale. It looks like for now many applications can't display properly UTF-8 encoded text (gnome apps, kde apps, bash all display raw two-byte chars, in menus as in the rest). So I thought "I'm testing it to report any bug or difficulty. If I can't find quickly how to fix this, I have to tell them because others will have problems, too." After looking in the new DrakConf (which seems a bit faster than the old one), considering linuxconf and webmin, I couldn't find another way to come back to ISO-Latin-15 than copying from another partition my 8.1's /etc/sysconfig/i18n . Why did you include UTF-8 support if it breaks ? (I was in expert mode, maybe it doesn't appear in normal mode ?) (I've other things to tell, but one mail for one thing is better.) -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr - philo du dimanche http://amphi-gouri.org/
Re: [Cooker] Exporting Display
On Tue, 26 Feb 2002, Mickey Newman wrote: > Since I have installed mdk 8.2 b I have not been able to export the display > from other machines and get it to work. Has the display numbers changed? > What should I be using on the host side and server side. > > I used to do a xhost + on my local machine and then export DISPLAY= ip>:0.0 > > Thanks > > Mickey (My answer does tackle with this problem precisely. Rather I say why you should be doing it another way. Please other people consider answering, too.) Short answer: connect to remote host with ssh -C nameofremotehost and everything will work fine. (-C enables compression, which is bad on a LAN, but excellent speedup with remote host, whatever the speed of your connection to the net). *Warning*: Don't do "xhost +", it is insecure ! It allows anyone to connect to your X session, display nasty windows on your screen, and spying all your interactions, including the passwords you may type in various programs. If your local network is accessible from outside, "anyone" really means everyone in the world! To avoid security problems, you should check that "xhost" alone always returns this: $ xhost access control enabled, only authorized clients can connect At our lab, we used to do: xhost remotehostname and on the remote side: export DISPLAY=nameoflocaldisplay:0 (:0 or :0.0 is synonym, :0.1 etc... are only meaningful with several screens on the same X server) But it allows any other users from the remote machine. The correct way is to allow only the remote machine to connect to your local display. This is done with the xauth program. Nowadays, things are much simpler for end users like us: use ssh (possibly with the "-X" option, depending on the ssh client configuration, by default it's not necessary with Mandrake Linux). ssh automatically creates the necessary permissions with xauth, and it's simple: ssh remotehost ssh -C -X remotehost (-C for compression, -X to ensure X calls are forwarded) $ hostname mydisplayhost.mydomain $ echo $DISPLAY :0 $ ssh remotehost Welcome to remotehost $ echo $DISPLAY mydisplayhost.mydomain:10.0 $ xeyes bash: xeyes: command not found $ whatever graphical application you like (The ":10.0" in $DISPLAY is normal: the display is forwarded in a secure crypted tunnel. The overhead is small, except on very slow machines.) -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr - philo du dimanche http://amphi-gouri.org/ "Bonjour, je ne suis qu'une phrase entre guillemets dans une signature, mais si vous me recopiez dans votre signature automatique d'e-mail, alors je pourrai continuer à me reproduire comme un virus. Merci !"
[Cooker] Mirroring both ISO and files on ftp
Hello everybody, Need: We need to setup a local Mandrake mirror (sorry, it can't be public). Moreover, disk space is limited and we'd like to mirror both ISO images and the "install by ftp" server (because we burn CDs of it from time to time). Constraint: But having both a copy of the ISO images and the file tree means duplicating the disk space (and network bandwith). We can't afford having several distributions and their ISO counterparts on our disk. Idea: There must be some way to share both via ftp, without duplication on the server disk space. Question: * Has anyone tried/succeeded ? Please explain how you did. * Any ideas ? (Independently of what I've already tried, see below) * 1st idea: mount all ISO images, use mount --bind to let Mandrake/RPMS2 and Mandrake/RPMS3 appear in the hierarchy of CD 1. This means sharing the mounted ISO image of CD 1, then creating Mandrake/RPMS2 and Mandrake/RPMS3 mount --bind helps, but only if the directory exists. But they don't exist by default. SUGGESTION to the Mandrake team: add two empty dirs RPMS2 and RPMS3 in the Mandrake/ directory of CD 1. . |-- Boot |-- Mandrake | |-- RPMS | |-- RPMS2 <<<--- empty dir, hook for mount --bind | |-- RPMS3 <<<--- empty dir, hook for mount --bind | |-- base | |-- mdkinst (...) | `-- share |-- doc |-- dosutils |-- images |-- misc `-- tutorial Then a simple shell-script calling mount would work fine. Like: mount CD1.iso Release/ -o loop mount CD2.iso CD2/ -o loop mount CD3.iso CD3/ -o loop mount --bind Release/Mandrake/RPMS2 CD2/Mandrake/RPMS2 mount --bind Release/Mandrake/RPMS3 CD3/Mandrake/RPMS3 Then the ISO images are available, and all the distribution is available through Release/ Please tell me what you think. * 2nd idea: use some not-well-documented features of mount (--bind --replace --after --before --over). I've tried variations like: mount --bind --after CD2/ Release/ It failed. All I could obtain is the regular mount --bind effect. Moreover, it seems that some ftp servers don't like crossing filesystem boundaries. Has anyone light on this ? Thanks! Why: (Why do this ? When a new Mandrake is released, the old one disappears very soon from public mirrors, and we need to keep some "old" versions for a while because migration is not straightforward, Mandrake upgrade process needs rebooting the machine and is always flakey). -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr - philo du dimanche http://amphi-gouri.org/ "Bonjour, je ne suis qu'une phrase entre guillemets dans une signature, mais si vous me recopiez dans votre signature automatique d'e-mail, alors je pourrai continuer à me reproduire comme un virus. Merci !"
Suggestion for a screensaver feature (Re: [Cooker] Please switch ofkdm AutoReLogin: painful and dangerous)
On Wed, 13 Feb 2002, SI Reasoning wrote: > > Whenever a screen is xlocked (xscreensaver, etc...), > > anyone just has to > > press Ctrl-Alt-Backspace to get re-logged in as the > > previous user, but > > without the screen locked. (See > > > http://www.google.com/search?q=autorelogin%20security) > > > > IMO, this should be turned off by default! > > (AutoReLogin=false in kdmrc) > > > > or maybe made a bit smarter, such as if password > authentication is checked in Xscreensaver then when it > autorelogins the Xsceensaver is automatically > activated. Or maybe send it to the screensaver > automatically regardless. I don't like the AutoReLogin feature. The X server (and process holding the session) should be stable. If it's not it has to be corrected. Relaunching a session automatically to pretend it's not nearly crashed is playing masquerade. But since it exists, there must be some way to make it better. IMHO, the real point here is: as long as a desktop session cannot be fully saved and restored, the AutoReLogin feature will be kind of flakey. This is the real point to improve. I have a suggestion (maybe it's what you thought, but here it is explicit): any screensaver may want to create a particular file (for example ~/.screen-locked -- common to all screen saver programs) to indicate that the screen is currently locked. If this file is present when the screensaver starts, it locks without waiting. When unlocking, the file is removed. It is not autorelogin's job to be aware of all particular screensavers, but it's up the the screensavers to agree to a (simple) way of telling that the screen was locked at the time X crashed. Hence I include a copy to the xscreensaver and kscreensaver maintainers. Thank you for your attention. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr - philo du dimanche http://amphi-gouri.org/
Re: [Cooker] Please switch of kdm AutoReLogin: painful and dangerous
On Wed, 13 Feb 2002, David BAUDENS wrote: > > IMO, this should be turned off by default! (AutoReLogin=false in > > kdmrc) > > /.../ > > It have never been actived by default. This is strange. I'm think I've never activated it (I discovered the option yesterday) and it was activated anyway. Thank you. -- Stéphane Gourichon
[Cooker] Please switch of kdm AutoReLogin: painful and dangerous
Hello, Mandrake 8.1 introduced a new feature, through the new kdm: AutoReLogin. It is supposed to build back the user session if X crashes (or Ctrl-Alt-Backspace is pressed, which is a handy way not to wait for eons for KDE to start when one actually wants everything else but KDE, but sometimes the default goes back to starting KDE anyway). Be aware that this opens a security hole ! Whenever a screen is xlocked (xscreensaver, etc...), anyone just has to press Ctrl-Alt-Backspace to get re-logged in as the previous user, but without the screen locked. (See http://www.google.com/search?q=autorelogin%20security) IMO, this should be turned off by default! (AutoReLogin=false in kdmrc) Perhaps, after disabling it by default, Mandrake may consider turning the default back to "on" in low security levels and/or if autologin is set to true. (I don't know, if it is fixed in 8.2, and I can't test now.) Thanks. -- Stéphane Gourichon - Labo. d'Informatique de Paris 6 - AnimatLab http://animatlab.lip6.fr - philo du dimanche http://amphi-gouri.org/ "Bonjour, je suis qu'une phrase entre guillemets dans une signature, mais si vous me recopiez dans votre signature automatique d'e-mail, alors je pourrai continuer à me reproduire comme un virus. Merci !"
Re: [Cooker] Suggest including amaya into next release.
On 21 Jun 2000, Pixel wrote: > Stephane Gourichon <[EMAIL PROTECTED]> writes: > > > It's available http://www.w3.org/Amaya/, and Daniel Veillard ( > > [EMAIL PROTECTED]) provides binary and soure RPMS. > > can't find the .src.rpm Sorry, I was convinced I saw it... The binary rpm I tried worked out of the box on my Mandrake 7.0. Perhaps kindly ask Daniel Veillard the spec file he made... -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
[Cooker] Suggest including amaya into next release.
Hello, It may be a good idea, IMHO, to include the official W3C HTML editor/browser, amaya. An overview is available on http://www.w3.org/Amaya/Amaya.html The main URL is http://www.w3.org/Amaya/ "Amaya is a complete web browsing and authoring environment and comes equipped with a WYSIWYG style of interface, similar to that of the most popular commercial browsers. With such an interface, users do not need to know the HTML or CSS languages." I like its structured editor (you can have a tree view of your page, and edit it in the tree). Like in Lyx, you can import a plain text file (or type it plain), and format it very quickly and easily: click on a paragraph, press "esc" to select the whole paragraph, then click on the "H1" button and have it become a H1 header. Table, images, image maps etc... are also easy to deal with. You can easily use CSS and modify the document appearance, without any prior knowledge of CSS, thanks to included documentation easy to find in the "help" menu. (BTW, it's i18nalized). A year ago it wasn't ready and had some widget problems (uses motif, I think). Now, I use it complementary with emacs and it's pretty useful to clean up html code produced by less-than-compliant editors and get it html4.0 compliant (which greatly helps keeping a consistent appearance of your pages through many browser, but subscribers of cooker mailing-list don't need this kind of explanation, I guess :-). It's available http://www.w3.org/Amaya/, and Daniel Veillard ( [EMAIL PROTECTED]) provides binary and soure RPMS. -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] Annoying problems with 7.1... urpmi
On 14 Jun 2000, Pixel wrote: > > The real problem occurs with > > gendepslist2 $DIR/hdlist.* > $DEPSLIST > > use rpmtools 1.1-24mdk > > tis fixed (not tested though, please report) I'll try and report (i want a working urpmi/rpmdrake before inciting friend to upgrade to 7.1). But the friend with the laptop is gone till next monday... I may try on one of my own computers (a P166+ underclocked at 120MHz like a P150+ for stability reason) this week and tell you if it work without and with this upgrade, else we'll wait until monday. See you. -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] will be Mandrake 7.1-2 distibution ?
On 9 Jun 2000, Guillaume Cottenceau wrote: > We're thinking of something like HelixUpdate -- but we can't come to a > whole agreement at MandrakeSoft, some of us think we should only install > only applicative stuff, > some others think we should handle a full upgrade > process this way (with the machine up). Great idea, that! I tried to upgrade a server from 6.1 to 7.0. I first grabbed rpmdrake and used it to uninstall a maximum of things with automatical dependencies, and then upgrade needed package, without halting the services or rebooting the server. Then I had problems with xfs (and others)... Services did continue to work, but we had a 6 hours power failure a few days later. Lilo did not work (it is a full SCSI machine), did not find initrd image for scsi module or something. After booting from floppy, I copied /etc to another partition, then installed 7.0 on mke2fs'ed / and /usr partition at a time I could afford having the server down. Still, an upgrade without reboot could be appreciated, but I guess it is *much* more difficult to *guarantee* it will work with any combination of glibc/processes/server-processes... is it bad to launch a /bin/bash in a rpm upgrade script when glibc is upgraded and the other rpms not ? I guess a major "unresolved symbol" syndrom may occur... :-( Someone told me that Debian updates itself completely without rebooting (except kernel change, I guess). How do they do that ? -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab
Re: [Cooker] Annoying problems with 7.1... urpmi
On 12 Jun 2000, Pixel wrote:
> > Pixel and others did a good job improving installation. Great.
> >
> > bootp/dhcp didn't work, though. Alt-F? said things like "/sbin/ifconfig:
> > not found" or the like, but manual config worked. (I should have written
> > that down...)
>
> tell more!
I'll write down those messages (if they appear) when I install mdk7.1 for
486 on my father's laptop.
> > : it is broken in 7.1 ...
>
> no it isn't. I use it everytime
>
> >
> > urpmi rpmdrake says "no package names rpmdrake"
>
> it means urpmi is not configured.
Of course: the urpmi.addmedia step doesn't complete...
> > wget was missing after install... isn't it needed by urpmi ?
> > dependencies say no.
>
> urpmi doesn't need wget. rpm is able to access ftp and http without any help.
> gurpmi does need wget via grpmi
Even for urpmi.addmedia for a ftp site ?
/usr/sbin/urpmi.addmedia:system("wget -O $HDLIST $url/$ftp_hdlist");
/usr/sbin/urpmi.addmedia:$? == 0 or die "wget of $url/$ftp_hdlist
failed (maybe wget is missing?)";
> > /etc/urpmi/urpmi.conf contained strange entries: in the path, the
>
> here is a working entry:
>
> ftp_2 ftp://a:a@leia//export/Mandrake/RPMS with ../base/hdlist.cz2
leia.mandrakesoft.com ? not in the dns... :-(
> cu Pixel.
--
Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab
"Bonjour, je suis un virus de signature de mail. Copiez moi dans votre
fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] Annoying problems with 7.1... urpmi
On Fri, 9 Jun 2000, Vincent wrote: > Try to delete all file in /var/lib/urpmi : > rm -f /var/lib/urpmi/* > and use urpmi.addmedia to rebuild the database information. I tried this several times, with different ftp sites, burned a CD-Rom and try urpmi.addmedia with it... no luck. The real problem occurs with gendepslist2 $DIR/hdlist.* > $DEPSLIST I can try it from the command line and gets a behaviour compatible with what Diablero said: > I have the same behaviour. After some debug, it seems that the pipe > open with popen can't never close :-( (I have a cyrix 166+). But on > another box (Bi-Celeron 400), it works great -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] Annoying problems with 7.1... urpmi
On Fri, 9 Jun 2000, Diablero wrote: > On Thu, Jun 08, 2000 at 11:01:41PM +0200, Stephane Gourichon wrote: > > I tried urpmi.removemedia and urpmi.addmedia to reset all this, tried > > another mirror... it downloads the hdlist correctly like in 7.0 (do I have > > to specify the hdlist of hdlist.cz2 file ? I tried both, no luck), then it > > says "generating dependencies list", and then throttles forever, cpu is > > sleeping. > > I have the same behaviour. After some debug, it seems that the pipe open > with popen can't never close :-( (I have a cyrix 166+). But on another box > (Bi-Celeron 400), it works great The problem appeared on that laptop, supposedly a Pentium 100, with a fresh Mdk7.1 installed from ftp.ciril.fr Here urpmi (the one in Mdk7.0) is used on Pentium 350-450MHz systems, and works ok. -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
[Cooker] Annoying problems with 7.1... urpmi
I just installed 7.1 on a small laptop (P100, 40Mo RAM, 800Mo HD) from network using pcmcia install. Pixel and others did a good job improving installation. Great. bootp/dhcp didn't work, though. Alt-F? said things like "/sbin/ifconfig: not found" or the like, but manual config worked. (I should have written that down...) I'm disappointed about urpmi (what I consider the killer utility for Mandrake; I remember when Pixel explained his idea to me during a lunch at Palaiseau, it was a great idea actually...) : it is broken in 7.1 ... urpmi rpmdrake says "no package names rpmdrake" wget was missing after install... isn't it needed by urpmi ? dependencies say no. /etc/urpmi/urpmi.conf contained strange entries: in the path, the "/Mandrake" part was missing, and other oddities. Surprisingly install worked correctly. I installed wget with manual ftp download. I tried urpmi.removemedia and urpmi.addmedia to reset all this, tried another mirror... it downloads the hdlist correctly like in 7.0 (do I have to specify the hdlist of hdlist.cz2 file ? I tried both, no luck), then it says "generating dependencies list", and then throttles forever, cpu is sleeping. This is very annoying for a "finished" product. Looks like this is a beta... ;) -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] future distro
On Wed, 31 May 2000, Marc B. Sitkin wrote:
> I'd also like to see any rpm install put an icon on the desktop to launch
> the newly installed program.
Please /don't/, I can't imagine my desktop stuffed with 420 icons!
Aren't you satisfied with the KDE and Gnome menus ?
Work is underway to make menus interoperable.
They are grouped under logical categories, which is better than having all
them sitting on the desktop.
Isn't it enough to open this url in kfm: file:~/.kde/share/applnk/ ?
Or execute this to test the effect on your desktop
find ~/.kde/share/applnk/ -exec cp -av {} ~/Desktop/ \;
> Regards,
>
> Marc Sitkin
--
Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab
"Bonjour, je suis un virus de signature de mail. Copiez moi dans votre
fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] Discussion : better stability: include set6x86
On Mon, 29 May 2000, Brook humphrey wrote: > Sorry to let you down but the most of the cyrix processors have had > stability problems. I see this problem allot in my computer store. The > problem is most likely not with the kernel but your processor. BTW, there is a utility names "set6x86" or something, that allows changing the internal flags of the Cyrix processor to enable/disable some subtle settings. The most interesting setting for the general user is the one that enables a low power consumption mode when the processor is idle. The power dissipated in the proc drops from something about 15-20 watts to 0.1 watts or so. This greatly reduces the temperature of the proc and keeps it more stable. (You can even *hear* the difference because it causes a slight difference in the fan speed, due to difference in power consumption, see set6x86 documentation for details). One of my computers is P166+-based, which I let actually run at 120MHz (2*60) like a P150+ because it seemed to hang often when I ran it at 2*66.6 as it should. I think it may be interesting to include this tool in future distributions, and a add a line into the installation process like grep -i cyrix < /proc/cpuinfo && select_package_for_install 'set6x86...' (or its perl equivalent). There is already a rpm for set6x86, there are things that make it unsuitable for direct inclusion into the distrib: -no startup script to call at boot time from /etc/rc.d/init.d/ -tool simply assumes the proc is a Cyrix and happily sets the registers (didn't make any harm to my AMD-K6, but detection is so simple to add) (I might even do that and offer you a ready-to-include .src.rpm, but I fear I lack time. If you ask...) -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] discussion of next distro
On Sun, 28 May 2000, Guy T. Rice wrote: > *I* don't generally use KDE (I prefer WindowMaker). KWinTV still works just > fine. I think it only requires Qt, but I've never checked, it might require > kdelibs too (but I don't think so)... It depends on the presence of kdelibs-devel at build-time, I think. If I remember well, the autoconf script checks for it, and if present you get the benefit of session handling and other subtleties of kde, if not you get a plain qt application. (This is one of many reason why .src.rpm are more powerful than precompiled ones). The choice is up to you now, to decide whether the kwintv binary rpm shipped with the distro should be compiled with or without the dependency on kdelibs. -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab
Re: [Cooker] Discussion : better stabilit
On Fri, 26 May 2000, diablero wrote:
> Can you add better stability ?
> Netscape often crash and get my box down.
It crashes too often (it's a shame).
But it never gets my box down.
> This bash line crash also my box (under a normal account):
> :(){ :|:&};
> :
I've just tried once, a few minutes ago on this PC (Mandrake 7.0) under my
usual X session. It indeed causes denial of service for a few minutes,
because the machine is busy forking until too many files/processes/memory
is eaten, then everything goes back to normal.
So, the machine does not crash either actually.
Even, none of my processes were killed (except the series of bash-gone-mad
caused by this command line).
--
Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab
"Bonjour, je suis un virus de signature de mail. Copiez moi dans votre
fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] Netscape app-defaults & wheel
On Fri, 26 May 2000, Bobby Dowling wrote: > On Thu, 25 May 2000, you wrote: > > What X-resource entries do i put in "/usr/X11R6/lib/app-defaults/Netscape" to > > get scroll to work ...where do i find this info? > > > > Can someone send me what is supposed to go in this so that my dang scroll wheel > works? > > Thank You Very Much!! > > Bobby Do you really need to tamper with this file ? I use netscape 4.70 included in 7.0, without imwheel and netscape window (and gtk file dialog) scroll with the mouse button... I did not edit any file. This is part of my /etc/X11/XF86Config (yes, I have a MS intellimouse :-(, and sometimes it bugs! The pointer on the screen shakes up and down, to the screen edge...). Does yours have a ZAxisMapping also ? Perhaps you should also put a "Buttons 5" of similar... ? # ** # Pointer section # ** Section "Pointer" Protocol"IMPS/2" Device "/dev/psaux" ZAxisMapping 4 5 # When using XQUEUE, comment out the above two lines, and uncomment # the following line. #Protocol "Xqueue" # Baudrate and SampleRate are only for some Logitech mice #BaudRate 9600 #SampleRate 150 # Emulate3Buttons is an option for 2-button Microsoft mice # Emulate3Timeout is the timeout in milliseconds (default is 50ms) #Emulate3Buttons #Emulate3Timeout50 # ChordMiddle is an option for some 3-button Logitech mice #ChordMiddle EndSection -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] Better availablilty of 486 distro
On Fri, 26 May 2000, Hoyt wrote: > I should have made myself more clear. There does exist a 486 version of > Mandrake 7.0, but it too low priority and is not available on fast servers. I should also have made myself clear. I downloaded and burned the 7.0 for my father's 486 laptop and already a friend of mine asked me for it and installed it on a desktop 486 at home. ** What I meant was: please continue to offer 486 versions of your future distributions, even if they are on very few mirrors. ** A side-effect of this is that people (newbie, journalists) will more easily understand and spread the knowledge that: 1) Mandrake is optimized for Pentium or better processors 2) Linux and especially Mandrake Linux can also run on old hardware. (Though you shouldn't try to launch Gnome + StarOffice on your 486 with 4 or 8Mb RAM, better stick with icewm or text mode or make it a small server). -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
[Cooker] Discussion: lack of stderr feedback under X: bring xconsole back!
Though Mandrake includes many improvements over previous distributions,
one user interface concern is still there: lack of stderr-like feedback
for X users.
Let me give some examples.
When a user under X runs a program from a broken window-manager menu
(still happens), the window-manager outputs an error message onto his
stderr, which is currently silently redirected by /etc/X11/xdm/Xsession to
the user's ~/.xsession-errors. Newbies don't know that, so they just see
that they click and nothing seems to happen.
When the user clicks on a terminal-based program in his file manager, the
program outputs a message on stderr/stdout. The file manager could offer a
"open in a terminal window" option, but not all do this. Same
problem. User wonders if something is broken, since nothing appears.
Suppose the user uses a floppy which happens to have bad sectors (am I
cursed ? This often happens to me, though I seldom use floppies). The
kernel will complain via syslog, which redirects to several places
(currently /dev/tty12 for example, but only if the user has chosen a
rather high security level). Again, the user has no clue why he cannot
retrieve his file.
Suggestion: bring xconsole back, with a suitable syslog/Xsession
configuration.
Currently /etc/X11/xdm/Xsetup_0 opens a console only if kdmdesktop isn't
available, which actually may be considered a bit illogical, unless you
considered that xconsole is good only for those who prefer old xdm instead
of kdm/gdm ?
Please do not include winbug-software-style read-then-click-to-close
dialog! xconsole is better: you can scroll back later and copy/paste, two
very important things that make those winbug-style dialogs lack.
A line like
kern.* /dev/console
in /etc/syslog.conf, and a modification to /etc/X11/xdm/Xsession like
this should do the trick:
--- XsessionFri May 26 20:38:20 2000
+++ Xsession_modified Fri May 26 20:51:36 2000
@@ -4,7 +4,7 @@
# redirect errors to a file in user's home directory if we can
-for errfile in "$HOME/.xsession-errors" "${TMPDIR-/tmp}/xses-$USER" "/tmp/xses-$USER"
+for errfile in /dev/console "$HOME/.xsession-errors" "${TMPDIR-/tmp}/xses-$USER"
+"/tmp/xses-$USER"
do
if ( cp /dev/null "$errfile" 2> /dev/null )
then
Actually the best would be to log both into /dev/console for instant view,
and ~/.xsession-errors for reference log.
I've tried things like exec 2>&1 | tee "$errfile" >/dev/console
but it didn't work and I couln't figure out an elegant solution.
(We could use
mkfifo /tmp/somefifo
tee /dev/console
exec > /tmp/somefifo 2>&1
but this is ugly, there must be a better solution.)
What is your opinion ?
Also, a last thing: since I sometime switch to console mode, especially to
do things as root, or cd burning, I dislike that logging to /dev/console
clutters the text screen. Could a subtle /dev/(tty*|console) line do the
following trick ?
-syslog goes to xconsole if present
-syslog goes to /dev/tty11
/but/ syslog doesn't clutter other ttys.
I couldn't figure out how to do this...
--
Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab
"Bonjour, je suis un virus de signature de mail. Copiez moi dans votre
fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] Better availablilty of 486 distro
On Fri, 26 May 2000, Hoyt wrote: > Once the 586 distro has gone gold, it should be trivial to re-compile > and produce the 486 distro. You lock yourself out of a large market by > not making the 486 version as available as the 586. I would love to > use it. I need it, too :-), for my 200Mb-hard-disk 486 laptop. A 486 version is an idea to keep, and get automatically done with every stable release. Many thanks! -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
[Cooker] A few urpmi-based improvements
(I wrote about several ideas in this mail, but they are all about urpmi and friends, so I think it is ok to have them in one mail.) (Also, I use 7.0 but have not fiddled with 7.1 beta or cooker a lot, so please pardon if I ask for something already done) On Fri, 26 May 2000, Hoyt wrote: > Install of rpm "foo" fails because it depends on rpm "bar". Install of > rpm "bar" fails because of libs.so.o which is included in > jhgy-1.0.rpm. Why don't you just "urpmi foo" or use rpmdrake ? (To mandrake people: urpmi is a *real* improvement to an rpm-based distribution! Thanks!) rpmdrake (because it is based on urpmi) is really more powerful than gnorpm or kpackage (though I haven't tried them recently). It is really clean to have un/install of package automatically propagate un/install of other to respect dependencies. urpmi needs some remarks, though: -It is a bit slow, even on a fast machine when there are complicated dependencies. -It doesn't process everything when you put many (say, 30 or more) rpms to install at the same time. I had to re-issue the command several times until it installs all. -/WISH/ a uninstall feature in urpmi command line. -/WISH/ Some urpmi-based tool that help keep a bunch of machine's installation consistent. (I used to have autorpm, but things could be better, thanks to urpmi.) Basically, the slave machines would contact (or be contacted by) the "master" machine to get the canonical "rpm -qa" list, compare with the local list, install what you don't have (with automatic dependencies), uninstall what you have but shouldn't, =but= have a config file that says "don't install/uninstall things such as XFree86-, kernel, nfs, samba-server..." (BTW, XFree86-Mach64|SVGA|... could be renamed to XFree86-server-*.rpm ... perhaps you did this already for XFree 4.0) -/WISH/ that urpmi handles dependencies for alien rpms: say, I find package gluz-blabla.i386.rpm on the web, that needs libmesa or whatever and Mesa gets installed automatically when I say : urpmi ftp://gluz.org/gluz-blabla.i386.rpm -/DREAM/ that urpmi handles dependencies when I find an alien .=SRC=.rpm (or .tar.gz, but I never "make install" of a tar.gz as root). In the former example it would install Mesa and Mesa-devel to compile gluz automatically. This will be of most importance for user John McLambda with non-intel architecture (Mac, for example... ? John like to have an easy-to-feed-with-software OS, like the one he used before Linux, but those i386.rpm from the web are useless, and John fears a .src.rpm is too complicated because at the moment no urpmi-like tools handles dependencies for compilation ... ) I know this one is tough, you'll probably have to process output from the make process of .src.rpm ... but, hey, a source package (or .tar.gz with a .spec file included) is a really relevant form for distributing free software. -/WISH/ Integrate rpm/urpmi/rpmdrake with the desktop and file manager (a bit like TkStep does). Easing two-way navigation between file tree and rpm tree within a single file manager environment could be *really* comfortable for the end user. For now, some people I've installed Linux gave up because they found it too cumbersome to look for documentation. Right-click on a file could say to which package it belongs, you can then jump to the list of files that this package includes, with several tabs "documentation files" "other files", so the user can at a glance see if the package include others executable and docs. I imagine them like the "panelize" function of mc: just a normal window of the file manager like any other, that allows double-click or right click like any other file icon, but files are shown with they full path. Of course, double-clicking on any doc file should bring a powerful and comfortable doc browser (customizable, also. I still prefer "man" in a terminal and "less /usr/doc/gluz/*" to browse the doc over all gnome-help-browser of kdehelp) Oops ! I hope I wasn't to verbose ! :-) Please tell me what you think. -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] GET READY FOR A DISCUSSION - Address dependency issue better
On Fri, 26 May 2000, Hoyt wrote: > > just use rpm --force ...e.g. i don't insall the mandrake_desk package becuse > > i don't ened it so i use --force for wmaker. it's only in some cases that > > you should use --force anyway. --nodeps is less ... forcing. > I often do just that =if= I understand what the dependency is all > about, and for the average new user, that will be never. Perhaps dependencies should be treated on several levels: -critical dependencies (i.e. the binaries won't work at all but say "shared library not found ...") -need for optional features (does pam always need cracklib ? does mpg123 always need esd ? [esd is too slow for a small pentium] ...) Sometimes a packages needs another only if certain hardware is used sndconfig doesn't need playmidi if your card doesn't support midi (okay, it doesn't take too much space and can be removed with --nodeps, only you have to /know/ that). But that's a job to extend the rpm standard and should be discussed with the rpm maintainers, it goes beyond the work of a distribution maker, doesn't it ? -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] [discuss] wine configuration
On Fri, 26 May 2000, John Grange wrote: > Guillaume Cottenceau wrote: > > > A good idea -- only problem is that [IMHO, i almost never used wine] you > > must be root to run wine no? > > > > -- > > Guillaume Cottenceau > > no you can be a normal user > the only reson for being root is if the config dir / and the drives selected > for wine (wich are actualy dirs ) are only wrtitable for root. easy way around > this is in the wine.conf file put $HOME/wine as the C drive or something to > that affect. > > -DarkWlf Wine configuration can be improved in the rpm shipped with future Mandrake distros. Some neat proposals are included in the wine documentation " A small WINE distribution guide. ". urpmi wine ; less /usr/doc/wine-*/distributors In short, they give rationales and sample implementations to allow maximum out-of-the-package functionality (root only has to urpmi/rpmdrake the package), while leaving users possibility of personal configuration for windows software, without world-writable directory or other undesirable thing. ; Using this trick we have in fact two windows installations in one, we ; get the stuff from the readonly installation and can write to our own. You may even get what a real windows environment lack: true multi-user compatibility, even with software that need to write in c:\windows. Why worry, I don't use windows software, anyway... :) but other people may need that. -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
Re: [Cooker] Graphical installer
Hello, On Fri, 26 May 2000, John Cavan wrote: > I don't think that you want to remove the choice of selecting > individual, optional packages. Yes, the expert user likes to precisely select what he wants to install. > What I recommend though is that you > remove all required packages from the list, which should trim the info > back a bit. I appreciated to see them in the list. I think it is good to let people know which packages will be installed whatever the user's choice. Perhaps make it an option to check ? "[x] hide required packages from the list" -- Stéphane Gourichon - Laboratoire d'Informatique de Paris 6 - Équipe AnimatLab "Bonjour, je suis un virus de signature de mail. Copiez moi dans votre fichier signature pour que je me propage désormais avec vos mails. Merci."
