[opensuse-factory] 10.2 Alpha4 - my installation report
This time I was little bit more thorough logging what I have seen. I like 1 CD installation. It loads basic system fast and than I can add whatever I want. I tried that with 10.2 alpha 4, but it doesn't work that way. 1) Hard disk choice doesn't exist as source of installation. Later I've found out that some actually exist in text mode installation, hidden in Network Installation, it goes trough Network settings (?!) and than asking for directory, but it doesn't work on iso images. I didn't tried again with installation source expanded to directories CD1 to CD5. 2) Next, I tried with CD 1 to install Base system and than fro running text mode install the rest. It requires some 500 MB, but also 4 CDs (?). What happened to idea to have 1 CD for essential stuff? 3) So I quited installation, added another 3 CDs and tried to install Base + AppArmor + Console. It gives > 1 GB including some KDE files and requires all 5 CDs. I didn't checked what was from KDE, I remember kdelibs. I guessed that Console means text mode and few more applications like "mc", not graphic mode Console. I interrupted installation at that moment. Package dependencies seems to grow system to classic bloat. 4) Than when it is needed all 5 CDs, I decided to install default KDE, but after warm boot to SUSE 10.0, CDRW disappeared. Cold boot solved the problem and was CD5 added to set. 5) It is already mentioned that partitioning proposals are given in a strange way. First it tried to remove 10.0 installation from /dev/hda1, and create two partitions, than tried to remove data partition, on the same disk, than I stopped to play with different menu options and went to expert and gave /dev/hdb1 for installation. Partitioner warned me that it will be better with swap. Good, swap exists, I added it buy entering dialog where all was set just to click to OK and exit. This might be somewhat shorter, and just explain that we need a swap and ask which one to include. 6) Next is kind of my mistake, I should review expert options and prevent boot loader installation, and later fiddling to give control back to 10.0. 7) Audio was not installed. I can't recall that it was ever mentioned. The adapter is plain VT8233/A/8235/8237 so something with detection wasn't OK. Taking long list of: udev[411]: lookup_group: <misc devices> not found (or missing), during initial hardware detection, it can be that. 8) On first boot after installation, I got huge letters on both screens. What means huge, few letters from the top-right corner of the screen. Not enough space for a single word. Go back to terminal (Ctrl-ALt-F2), log in as root and start sax2. The same problem. No normal way out, but Ctrl-ALt-Back Space to kill X. I'm used to handle huge virtual screen like 1280x1024 in small real resolution, but this was not the same case. Mouse pointer went from side to side and didn't moved the screen. I have no good experience with sax in uncommon cases. I tried to start mc. Ups, it is not installed by default. Yast was installed so go and buy mc. With mc it showed up that Gateway EV500 15" monitor physical size was set to 28 21 in xorg.conf. This is correct in centimeters, but xorg server expects millimeters. Add 0 behind both and restart X. Desktop came back, only icons were randomly dropped around. Probably KDE was confused due to previous bad setting in xorg.conf. Many icons one over another. 9) The Main Menu is huge. Font is now OK, but surface is far beyond screen. Restarting KDE doesn't help. Go back to mc and find in users .kde directory kickerrc. Menu size was KMenuHeight=1950 KMenuWidth=3160 resize to 400x600 and restart KDE again. Menu is good now. This must be due to same 28x21 (cm) screen size that is probably bad entry in monitor DB. 10) As mentioned Midnight Commander is not installed by default. It should be in Alpha version. It is swiss army knife for troubleshooting. More I think, it should be included Base pattern anyway. 11) Now I need tiny-nvidia-installer to make use of MX4000 adapter. For now I don't know easier way to have nvidia drivers installed. Use YaST and install it. I know that I need kernel sources. They are not listed as dependency of installer, only xorg-X11-server-sdk, and that pulls in all of xorg development. Interesting. 12) gcc is not prerequisite (dependency) of kernel sources. If gcc is not installed what can I do with sources? I came with system configuration this far. Nvidia is left for some other day. 13) Attempt to see Krita that is in the same category as GIMP, finished with application crash. I'll try to see how to reproduce this. General 10.2 is nice and fast, and excluding installation, I can't see major problems. -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rajko M <rmatov101@charter.net> writes:
This time I was little bit more thorough logging what I have seen.
I like 1 CD installation. It loads basic system fast and than I can add whatever I want. I tried that with 10.2 alpha 4, but it doesn't work that way.
I know - and this will happen only with Beta1 again. First we need to get the patterns list fixed.
1) Hard disk choice doesn't exist as source of installation. Later I've found out that some actually exist in text mode installation, hidden in Network Installation, it goes trough Network settings (?!) and than asking for directory, but it doesn't work on iso images. I didn't tried again with installation source expanded to directories CD1 to CD5.
2) Next, I tried with CD 1 to install Base system and than fro running text mode install the rest. It requires some 500 MB, but also 4 CDs (?). What happened to idea to have 1 CD for essential stuff?
See above.
3) So I quited installation, added another 3 CDs and tried to install Base + AppArmor + Console. It gives > 1 GB including some KDE files and requires all 5 CDs. I didn't checked what was from KDE, I remember kdelibs. I guessed that Console means text mode and few more applications like "mc", not graphic mode Console. I interrupted installation at that moment. Package dependencies seems to grow system to classic bloat.
Please discuss the list of patterns and what you propose to change. I want to avoid bloat!
4) Than when it is needed all 5 CDs, I decided to install default KDE, but after warm boot to SUSE 10.0, CDRW disappeared. Cold boot solved the problem and was CD5 added to set.
5) It is already mentioned that partitioning proposals are given in a strange way. First it tried to remove 10.0 installation from /dev/hda1, and create two partitions, than tried to remove data partition, on the same disk, than I stopped to play with different menu options and went to expert and gave /dev/hdb1 for installation. Partitioner warned me that it will be better with swap. Good, swap exists, I added it buy entering dialog where all was set just to click to OK and exit. This might be somewhat shorter, and just explain that we need a swap and ask which one to include.
6) Next is kind of my mistake, I should review expert options and prevent boot loader installation, and later fiddling to give control back to 10.0.
7) Audio was not installed. I can't recall that it was ever mentioned. The adapter is plain VT8233/A/8235/8237 so something with detection wasn't OK. Taking long list of: udev[411]: lookup_group: <misc devices> not found (or missing), during initial hardware detection, it can be that.
yast2-sound was not installed - fixed now.
9) The Main Menu is huge. Font is now OK, but surface is far beyond screen. Restarting KDE doesn't help. Go back to mc and find in users .kde directory kickerrc. Menu size was KMenuHeight=1950 KMenuWidth=3160 resize to 400x600 and restart KDE again. Menu is good now. This must be due to same 28x21 (cm) screen size that is probably bad entry in monitor DB.
Please report this in bugzilla.
12) gcc is not prerequisite (dependency) of kernel sources. If gcc is not installed what can I do with sources?
Read them ? ;-)
I came with system configuration this far. Nvidia is left for some other day.
13) Attempt to see Krita that is in the same category as GIMP, finished with application crash. I'll try to see how to reproduce this.
General 10.2 is nice and fast, and excluding installation, I can't see major problems.
Thanks, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
Rajko M <rmatov101@charter.net> writes:
This time I was little bit more thorough logging what I have seen.
I like 1 CD installation. It loads basic system fast and than I can add whatever I want. I tried that with 10.2 alpha 4, but it doesn't work that way.
I know - and this will happen only with Beta1 again. First we need to get the patterns list fixed.
OK. I guessed that was the reason, but direct answer will help not to repeat the question. ...
3) So I quited installation, added another 3 CDs and tried to install Base + AppArmor + Console. It gives > 1 GB including some KDE files and requires all 5 CDs. I didn't checked what was from KDE, I remember kdelibs. I guessed that Console means text mode and few more applications like "mc", not graphic mode Console. I interrupted installation at that moment. Package dependencies seems to grow system to classic bloat.
Please discuss the list of patterns and what you propose to change. I want to avoid bloat!
I have to go trough above pattern, to see what happened, before I can discuss anything. BTW, it might be good to sort results of previous thread on basic pattern and repeat the question. Something like phase 2. ...
7) Audio was not installed. I can't recall that it was ever mentioned. The adapter is plain VT8233/A/8235/8237 so something with detection wasn't OK. Taking long list of: udev[411]: lookup_group: <misc devices> not found (or missing), during initial hardware detection, it can be that.
yast2-sound was not installed - fixed now.
Thanks.
9) The Main Menu is huge. Font is now OK, but surface is far beyond screen. Restarting KDE doesn't help. Go back to mc and find in users .kde directory kickerrc. Menu size was KMenuHeight=1950 KMenuWidth=3160 resize to 400x600 and restart KDE again. Menu is good now. This must be due to same 28x21 (cm) screen size that is probably bad entry in monitor DB.
Please report this in bugzilla.
12) gcc is not prerequisite (dependency) of kernel sources. If gcc is not installed what can I do with sources?
Read them ? ;-)
What about to fix prerequisites :-) Is it fixed (?). ... -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, On Wednesday 13 September 2006 01:10, Rajko M wrote:
Andreas Jaeger wrote:
Rajko M <rmatov101@charter.net> writes:
12) gcc is not prerequisite (dependency) of kernel sources. If gcc is not installed what can I do with sources?
Read them ? ;-)
What about to fix prerequisites :-) Is it fixed (?).
There is no need to fix it. Even though there was a smiley on Andreas comment, it is absolutely a fair point. I often install the kernel sources (for reference) and don't need gcc for that. You complained about the default install being too bloated: "Package dependencies seems to grow system to classic bloat." See? ;-) I also would vote against mc in the default selection. I don't dispute it being a useful tool. But *many* people will never use it. So why install it by default. Those that are likely to use it can be assumed to know how to install the additional package. Greetings from Stuhr hartmut -- Hartmut Meyer, NTS EMEA Partner Relationship Manager SUSE LINUX GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 421 3064385 - M: +49 179 2279480 F: +49 421 3064387 - hartmut.meyer@novell.com ---------------------------------------------------- SUSE® Linux Enterprise 10 - Your Linux is ready http://www.novell.com/linux
Rajko M <rmatov101@charter.net> writes:
What about to fix prerequisites :-)
Is an option but do we really want this? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
Rajko M <rmatov101@charter.net> writes:
What about to fix prerequisites :-)
Is an option but do we really want this?
Andreas
I installed nvidia on 10.1 using tiny-nvidia-installer, and it wanted to download some kernel sources. What that would do to the system I can only guess, as I interrupted installer, installed and updated SUSE kernel sources and run installer again. This time although I forgot to prepare kernel sources, installer did that for me, and installation was successful. That is reason to ask for gcc. I know how to handle this, but new to Linux will get lost, and we will have to handle a lot of help requests from them. You know that I'm against bloat, but in this scenario loading gcc with kernel sources is needed. The other option to handle this is to instruct tiny-nvidia-installer to give message with options, and if user select installation to install prerequisites. Another option is weak dependency, as Christian mentioned, but I haven't seen recently packages that will be installed to satisfy dependencies and have check box enabled, which would be sign that I can remove them from selection. -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, Rajko M schrieb:
That is reason to ask for gcc. I know how to handle this, but new to Linux will get lost, and we will have to handle a lot of help requests from them.
PLEASE. The web is full of - forum posts - wiki entries - other documentation resources which clearly say: "In order to compile a kernel module, the packages gcc, make and kernel-source are needed." The user will "get lost" only if he's not interested in getting the job done anyway.
Another option is weak dependency, as Christian mentioned, but I haven't seen recently packages that will be installed to satisfy dependencies and have check box enabled, which would be sign that I can remove them from selection.
That's because "weak" dependencies are not weak at all. There are just two cases: - The package that another package depends on is installed by default. This is the case with "Requires" and "Recommends". "Requires" == "Recommends" here. - The package that another package depends on is not installed by default. This is the case with "Suggests". "Suggests" is very similar to not having a dependency at all. There is no intermediate step between these and no way to prevent a "Recommended" package from being installed other than installing it and uninstalling it again or setting the package to "taboo" - which requires the user to know in advance that the dependency is meant to be "weak". I can explain why I don't like the idea of kernel-source depending on gcc: It breaks the concept of being able to replace the system compiler that has just now been introduced, because it will force the system compiler to be installed even if the user already has another compiler. On the other hand, you might argue that kernel modules must be built with the system compiler anyway... And that's correct. So maybe the proposal makes sense, but I'm unsure. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Andreas Hanke wrote:
Hi,
Rajko M schrieb:
That is reason to ask for gcc. I know how to handle this, but new to Linux will get lost, and we will have to handle a lot of help requests from them.
PLEASE.
The web is full of
- forum posts - wiki entries - other documentation resources
which clearly say:
"In order to compile a kernel module, the packages gcc, make and kernel-source are needed."
The user will "get lost" only if he's not interested in getting the job done anyway.
I remember my start with Linux. I had strong interest to succeed, but many times it looked to me like a lost case. 1) Documentation in many fields obsolete, insufficient or missing, 2) Books, not many and obsolete even fresh out of the print, often artificially oversized, as number of the pages makes them look serious and sell better. 3) Altavista (at the time top search engine) not very helpful, as one has to know right words. Synonyms will lead in wrong direction, and I knew only terms used in other OS. 4) Linux is different enough, that more you know about another option, more problems you have to overcome. So, it is not always user interest (lack of) to make people feel lost.
Another option is weak dependency, as Christian mentioned, but I haven't seen recently packages that will be installed to satisfy dependencies and have check box enabled, which would be sign that I can remove them from selection.
That's because "weak" dependencies are not weak at all.
There are just two cases:
- The package that another package depends on is installed by default. This is the case with "Requires" and "Recommends". "Requires" == "Recommends" here.
This is probably because how it is treated in package management software ie. "Recommends" will be marked for installation without any additional question or special marks that you can skip it loosing some functionality.
- The package that another package depends on is not installed by default. This is the case with "Suggests". "Suggests" is very similar to not having a dependency at all.
There is no intermediate step between these and no way to prevent a "Recommended" package from being installed other than installing it and uninstalling it again or setting the package to "taboo" - which requires the user to know in advance that the dependency is meant to be "weak".
Taboo option is something that many users learn long time after they start to use Software management. The same is with option to remove software after installation, besides that it includes 2 operations that should not happen at all.
I can explain why I don't like the idea of kernel-source depending on gcc: It breaks the concept of being able to replace the system compiler that has just now been introduced, because it will force the system compiler to be installed even if the user already has another compiler.
On the other hand, you might argue that kernel modules must be built with the system compiler anyway... And that's correct. So maybe the proposal makes sense, but I'm unsure.
I'm a bit puzzled. If different compiler gives correct code for another applications, what makes it unable to compile kernel modules? Missing some special kernel module API, or sort of it. Sorry, but non-programmers need few words more. If this, about system compiler, is hard fact, than there is nothing to be unsure about. I don't like few hundreds MB more, just to be able to run video adapter in full featured mode, but if I have to, then there is no options. I either have kernel sources and gcc installed, and used, or I have no 3D, and for instance Google Earth runs skipping the frames (nvidia with nv driver) or not at all (old ati board with ati driver). -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rajko M schrieb:
If this, about system compiler, is hard fact, than there is nothing to be unsure about. I don't like few hundreds MB more, just to be able to run video adapter in full featured mode, but if I have to, then there is no options. I either have kernel sources and gcc installed, and used, or I have no 3D, and for instance Google Earth runs skipping the frames (nvidia with nv driver) or not at all (old ati board with ati driver).
So you really, really want gcc to be installed by default together with kernel-source, and it is unacceptable to the well-known novice user that he must figure out that a compiler is needed in order to compile a kernel module? OK. But then, make must be added there as well, because gcc and make are exactly equally required in order to compile a custom kernel or a module for the currently running kernel. Adding gcc, but not adding make seems nonsensical to me. A few offtopic remarks: - Alternative package managers like smart, apt and yum will completely ignore "Recommends", while zypp will handle it almost like "Requires". This behaviour difference might confuse users and is one of the reasons why I'd like to see the use of "Recommends" restricted to special cases. - While investigating the Factory tree for this issue, I found out that a few -devel packages already have hard dependencies to gcc while others don't have them at all. It would be nice if there could be some sort of policy. Proposal: - -devel packages should not have any dependencies to any compiler, neither weak nor hard, in order to allow replacing the system compiler easily without breaking dependencies. - package kernel-source needs more discussion; adding a dependency to gcc and make here is IMHO actually more useful than the gcc dependencies within -devel packages. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Andreas Hanke <andreas.hanke@gmx-topmail.de> writes:
Rajko M schrieb:
If this, about system compiler, is hard fact, than there is nothing to be unsure about. I don't like few hundreds MB more, just to be able to run video adapter in full featured mode, but if I have to, then there is no options. I either have kernel sources and gcc installed, and used, or I have no 3D, and for instance Google Earth runs skipping the frames (nvidia with nv driver) or not at all (old ati board with ati driver).
So you really, really want gcc to be installed by default together with kernel-source, and it is unacceptable to the well-known novice user that he must figure out that a compiler is needed in order to compile a kernel module?
Just use the kernel development pattern and install it - you get everything directly.
OK. But then, make must be added there as well, because gcc and make are exactly equally required in order to compile a custom kernel or a module for the currently running kernel. Adding gcc, but not adding make seems nonsensical to me.
A few offtopic remarks:
- Alternative package managers like smart, apt and yum will completely ignore "Recommends", while zypp will handle it almost like "Requires". This behaviour difference might confuse users and is one of the reasons why I'd like to see the use of "Recommends" restricted to special cases.
- While investigating the Factory tree for this issue, I found out that a few -devel packages already have hard dependencies to gcc while others don't have them at all. It would be nice if there could be some sort of policy.
Proposal:
- -devel packages should not have any dependencies to any compiler, neither weak nor hard, in order to allow replacing the system compiler easily without breaking dependencies.
Agreed.
- package kernel-source needs more discussion; adding a dependency to gcc and make here is IMHO actually more useful than the gcc dependencies within -devel packages.
Could any of you file a bug, please? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger schrieb:
Just use the kernel development pattern and install it - you get everything directly.
Wait - the kernel development pattern includes more packages than needed for just building external modules, including large and potentially undesired ones like kernel-debug and kernel-um. The user might end up with kernel-debug being booted by default. So this pattern is the right thing for developers, but not for users who just want to build their favorite gfx driver. Adding yet another smaller pattern with just kernel-source, gcc and make for building external modules is probably overkill, we should not explode the number of patterns infinitely.
- package kernel-source needs more discussion; adding a dependency to gcc and make here is IMHO actually more useful than the gcc dependencies within -devel packages.
Could any of you file a bug, please?
Maybe I'll do it once I'm really convinced that doing this is a good idea ;-) Or someone who is already convinced, go ahead and do it. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Sep 14, 2006 at 05:29:43PM +0200, Andreas Hanke wrote:
The user might end up with kernel-debug being booted by default. So this
Does this happen with the current package? If so, I'd consider this a bug and you might want to file a bug report. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Robert Schiele schrieb:
Does this happen with the current package?
Yes, installing kernel-debug on a Factory system where there was only kernel-default installed renames the existing vmlinuz and initrd symlinks to .previous and creates new ones pointing to kernel-debug, effectively making kernel-debug the default. The conclusion is that the kernel development pattern is not the right thing for users who just need to build an external module.
If so, I'd consider this a bug and you might want to file a bug report.
I won't file a bug report because I'm not sure that this is a real bug. It makes sense, someone who installs kernel-debug most likely wants to use it, and someone who doesn't want to use it should rather not install it. Unfortunately, it renders the kernel development pattern a no-go for just building external modules, and that in turn backs the point of having kernel-source depend on gcc and make, so that users can install a single package to get a complete kernel module build environment. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Andreas Hanke <andreas.hanke@gmx-topmail.de> writes:
Robert Schiele schrieb:
Does this happen with the current package?
Yes, installing kernel-debug on a Factory system where there was only kernel-default installed renames the existing vmlinuz and initrd symlinks to .previous and creates new ones pointing to kernel-debug, effectively making kernel-debug the default.
The conclusion is that the kernel development pattern is not the right thing for users who just need to build an external module.
So, should I change the pattern? I can make kernel-debug completely optional...
If so, I'd consider this a bug and you might want to file a bug report.
I won't file a bug report because I'm not sure that this is a real bug. It makes sense, someone who installs kernel-debug most likely wants to use it, and someone who doesn't want to use it should rather not install it.
Unfortunately, it renders the kernel development pattern a no-go for just building external modules, and that in turn backs the point of having kernel-source depend on gcc and make, so that users can install a single package to get a complete kernel module build environment.
Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Thu, 14 Sep 2006, Andreas Jaeger wrote:
Andreas Hanke <andreas.hanke@gmx-topmail.de> writes:
Robert Schiele schrieb:
Does this happen with the current package? Yes, installing kernel-debug on a Factory system where there was only kernel-default installed renames the existing vmlinuz and initrd symlinks to .previous and creates new ones pointing to kernel-debug, effectively making kernel-debug the default.
The conclusion is that the kernel development pattern is not the right thing for users who just need to build an external module.
So, should I change the pattern? I can make kernel-debug completely optional...
I know that we probably do not want an other pattern but given all the issuses maybe an other pattern would be the best solution. "Modules extrenal build" I really would like to keep the debug stuff in the kernel-debug. When I have to debug kernel issues, I really want the complete stuff even with the debug being the default kernel to use. Just my $.02 -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 14 September 2006 13:34, Andreas Jaeger wrote: > So, should I change the pattern? I can make kernel-debug completely > optional... It would be great if kernel-debug could be made optional AND 1) if it can also co-exist with kernel-default 2) have its own bootloader entries rather than stealing /boot/vmlinuz and /boot/initrd It would also be great if crash Require'd kernel-debuginfo. The kernel-*-debuginfo packages would need to Provide kernel-debuginfo, so that when crash was selected for installation the correct kernel-*-debuginfo was selected based on the currently installed kernel (default or bigsmp) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, Warren Stockton schrieb:
It would be great if kernel-debug could be made optional AND 1) if it can also co-exist with kernel-default
What does co-existance mean in this context? Multiple kernel packages can already be installed in parallel - do you mean something else?
2) have its own bootloader entries rather than stealing /boot/vmlinuz and /boot/initrd
Installing any kernel package in addition to an already installed one does the following: - Rename the existing vmlinuz and initrd symlinks to .previous - Create new vmlinuz and initrd symlinks pointing to the just installed kernel - Create a new bootloader entry named "Previous kernel" pointing to the .previous symlinks Changing this behaviour for kernel-debug is questionable because the same script is being used for all kernel flavours. It would be some work and also a bit inconsistent IMHO - currently the last installed kernel "wins", but the previous one is still available.
It would also be great if crash Require'd kernel-debuginfo. The kernel-*-debuginfo packages would need to Provide kernel-debuginfo, so that when crash was selected for installation the correct kernel-*-debuginfo was selected based on the currently installed kernel (default or bigsmp)
This is not trivial because the -debuginfo packages are autogenerated by a script. I don't know if it's even possible to add dependencies manually for these packages. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Sep 15, 2006 at 12:18:12AM +0200, Andreas Hanke wrote:
Changing this behaviour for kernel-debug is questionable because the same script is being used for all kernel flavours. It would be some work and also a bit inconsistent IMHO - currently the last installed kernel "wins", but the previous one is still available.
Well, we have some exception code already for the xen kernels. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Andreas Jaeger schrieb:
So, should I change the pattern?
Let's not hurry. ;-)
I can make kernel-debug completely optional...
Maybe. That might be an option for other reasons as well - I tend to find a pattern changing the default kernel rather obtrusive and maybe surprising, because not all KMPs are available for kernel-debug. The user might end up with effects (missing modules...) that he did not expect. On the other hand, I'd like to hear more opinions of people who will use this pattern for actual development purposes and not just building an external module. How much sense does the pattern make without kernel-debug being installed by default? Some brainstorming why this discussion started: There was a request to simplify the way of getting a build environment for external modules (3D gfx drivers in particular). This request is legitimate. There are multiple proposed solutions: 1) Advise the user to install packages gcc, make and kernel-source individually. Advantage: Is simple, will always work for everyone under any circumstances, is portable across all earlier and future openSUSE distributions and even foreign distributions, does not introduce any avoidable overhead on the user's machine. => Easy to support. Disadvantage: Some manual intervention needed. 2) Change package kernel-source to have a soft or hard requirement to gcc and make. Advantage: Is simple. Disadvantage: Significant change compared to earlier SUSE releases, a soft requirement will not work with other package managers than zypp. 3) Advise the user to install the kernel development pattern. Advantage: Is simple. Disadvantage: Will introduce overhead on the users machine - packages which clearly belong into this pattern, but are not needed for external module builds; will change the default kernel. 4) Create a new pattern that includes just the bare minimum needed to build external modules. Advantage: ? Disadvantage: Bloats the already impressive number of patterns even further. 5) Reduce the kernel development pattern to make kernel-debug optional. Advantage: Avoids the default kernel switch (see 3), maybe desirable even independently of this issue. Disadvantage: Will still introduce other packages than kernel-debug that are not needed for external module builds either; might be perceived as degrading functionality of this pattern; first negative feedback from an actual kernel developer already there. I'd go for either 1), 2) or 5), based on more opinions from different people.
From a user's perspective, a one-click solutions is desirable, but I wouldn't call it something that "must" be done. Sticking to 1) is not catastrophic if a better and universally acceptable solution is not found.
Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Andreas Hanke <andreas.hanke@gmx-topmail.de> writes:
Andreas Jaeger schrieb:
So, should I change the pattern?
Let's not hurry. ;-)
I can make kernel-debug completely optional...
Maybe. That might be an option for other reasons as well - I tend to find a pattern changing the default kernel rather obtrusive and maybe surprising, because not all KMPs are available for kernel-debug. The user might end up with effects (missing modules...) that he did not expect.
On the other hand, I'd like to hear more opinions of people who will use this pattern for actual development purposes and not just building an external module. How much sense does the pattern make without kernel-debug being installed by default?
Nobody has answered so far - so what should be done?
Some brainstorming why this discussion started:
There was a request to simplify the way of getting a build environment for external modules (3D gfx drivers in particular).
This request is legitimate.
There are multiple proposed solutions:
1) Advise the user to install packages gcc, make and kernel-source individually.
Advantage: Is simple, will always work for everyone under any circumstances, is portable across all earlier and future openSUSE distributions and even foreign distributions, does not introduce any avoidable overhead on the user's machine. => Easy to support.
Disadvantage: Some manual intervention needed.
2) Change package kernel-source to have a soft or hard requirement to gcc and make.
Advantage: Is simple.
Disadvantage: Significant change compared to earlier SUSE releases, a soft requirement will not work with other package managers than zypp.
3) Advise the user to install the kernel development pattern.
Advantage: Is simple.
Disadvantage: Will introduce overhead on the users machine - packages which clearly belong into this pattern, but are not needed for external module builds; will change the default kernel.
4) Create a new pattern that includes just the bare minimum needed to build external modules.
Advantage: ?
Disadvantage: Bloats the already impressive number of patterns even further.
5) Reduce the kernel development pattern to make kernel-debug optional.
Advantage: Avoids the default kernel switch (see 3), maybe desirable even independently of this issue.
Disadvantage: Will still introduce other packages than kernel-debug that are not needed for external module builds either; might be perceived as degrading functionality of this pattern; first negative feedback from an actual kernel developer already there.
I'd go for either 1), 2) or 5), based on more opinions from different people.
So, what do you all think?
From a user's perspective, a one-click solutions is desirable, but I wouldn't call it something that "must" be done. Sticking to 1) is not catastrophic if a better and universally acceptable solution is not found.
Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Thu, Sep 21, 2006 at 01:39:43PM +0200, Andreas Jaeger wrote:
On the other hand, I'd like to hear more opinions of people who will use this pattern for actual development purposes and not just building an external module. How much sense does the pattern make without kernel-debug being installed by default?
Nobody has answered so far - so what should be done?
As I already mentioned would consider kernel-debug installed as the default kernel a bug and thus would handle it in a similar way as the xen kernel in the postinstall script. If you do so it can no longer hurt anyone installing it by accident because it has to be booted in an explicit way if wanted. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Robert Schiele <rschiele@gmail.com> writes:
On Thu, Sep 21, 2006 at 01:39:43PM +0200, Andreas Jaeger wrote:
On the other hand, I'd like to hear more opinions of people who will use this pattern for actual development purposes and not just building an external module. How much sense does the pattern make without kernel-debug being installed by default?
Nobody has answered so far - so what should be done?
As I already mentioned would consider kernel-debug installed as the default kernel a bug and thus would handle it in a similar way as the xen kernel in the postinstall script. If you do so it can no longer hurt anyone installing it by accident because it has to be booted in an explicit way if wanted.
Could you file a bugreport for this, please? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Thu, 21 Sep 2006, Andreas Jaeger wrote:
Andreas Hanke <andreas.hanke@gmx-topmail.de> writes:
Nobody has answered so far - so what should be done?
4) Create a new pattern that includes just the bare minimum needed to build external modules.
Advantage: ?
Disadvantage: Bloats the already impressive number of patterns even further.
So, what do you all think?
I said, I prefered this one. I tend to find a pattern changing the default kernel rather obtrusive because not all KMPs are available for kernel-debug. The user might end up with effects (missing modules...) that he did not expect. And could be rather hard for a non advanced user to deal with. -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Sep 14, 2006 at 08:42:12PM +0200, Andreas Hanke wrote:
I won't file a bug report because I'm not sure that this is a real bug. It makes sense, someone who installs kernel-debug most likely wants to use it, and someone who doesn't want to use it should rather not install it.
And you think he wants to use it as _default_ kernel? Well, ok... Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Hello, Am Mittwoch, 13. September 2006 01:10 schrieb Rajko M:
Andreas Jaeger wrote:
Rajko M <rmatov101@charter.net> writes: [...]
12) gcc is not prerequisite (dependency) of kernel sources. If gcc is not installed what can I do with sources?
Read them ? ;-)
What about to fix prerequisites :-) Is it fixed (?).
What about adding gcc and make as weak dependencies to kernel-source? "Recommends" would be a good option IMHO. BTW: I just wonder that kernel sources from 10.1 (didn't check 10.2 yet) require /sbin/insserv - did I miss something or is this a packaging bug? Regards, Christian Boltz -- printk("; corrupted filesystem mounted read/write - your computer will explode within 20 seconds ... but you wanted it so!\n"); [/usr/src/linux/fs/hpfs/super.c] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Christian Boltz schrieb:
What about adding gcc and make as weak dependencies to kernel-source? "Recommends" would be a good option IMHO.
"Recommends" is not as great as many people think. There was another similar change recently in another package (involving ft2demos, causing it to be installed by default on all systems even though it is usually not needed) that really annoyed me, I'll have to find it again and make a comment... In this specific case it might be OK, but then I'll ask why we don't make gcc a (weak or strong, whatever) dependency of every single -devel package. Ah, and of course gcc-c++ for C++ libraries. Many different things can be done with source code, compiling it is just one use case. Asking the user to figure out himself that he needs gcc to compile the kernel is not too much in my eyes.
BTW: I just wonder that kernel sources from 10.1 (didn't check 10.2 yet) require /sbin/insserv - did I miss something or is this a packaging bug?
It is not a packaging bug. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Andreas Jaeger wrote: > Rajko M <rmatov101@charter.net> writes: ... >> 9) The Main Menu is huge. Font is now OK, but surface is far beyond >> screen. Restarting KDE doesn't help. Go back to mc and find in users >> .kde directory kickerrc. Menu size was >> KMenuHeight=1950 >> KMenuWidth=3160 >> resize to 400x600 and restart KDE again. >> Menu is good now. This must be due to same 28x21 (cm) screen size that >> is probably bad entry in monitor DB. > > Please report this in bugzilla. ... Reported: 1) Missing HD as installation source: https://bugzilla.novell.com/show_bug.cgi?id=205369 2) Incorrect screen size for monitor Gareway EV500. (should be Gateway :-) sorry) https://bugzilla.novell.com/show_bug.cgi?id=205371 3) Huge Main Menu https://bugzilla.novell.com/show_bug.cgi?id=205373 -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Dňa Ut 12. September 2006 05:40 Rajko M napísal:
This time I was little bit more thorough logging what I have seen.
[snip]
5) It is already mentioned that partitioning proposals are given in a strange way. First it tried to remove 10.0 installation from /dev/hda1, and create two partitions, than tried to remove data partition, on the same disk, than I stopped to play with different menu options and went to expert and gave /dev/hdb1 for installation. Partitioner warned me that it will be better with swap. Good, swap exists, I added it buy entering dialog where all was set just to click to OK and exit. This might be somewhat shorter, and just explain that we need a swap and ask which one to include.
Please, file an enhancement into bugzilla. Stano --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Stanislav Visnovsky wrote:
Dňa Ut 12. September 2006 05:40 Rajko M napísal:
This time I was little bit more thorough logging what I have seen.
[snip]
5) It is already mentioned that partitioning proposals are given in a strange way. First it tried to remove 10.0 installation from /dev/hda1, and create two partitions, than tried to remove data partition, on the same disk, than I stopped to play with different menu options and went to expert and gave /dev/hdb1 for installation. Partitioner warned me that it will be better with swap. Good, swap exists, I added it buy entering dialog where all was set just to click to OK and exit. This might be somewhat shorter, and just explain that we need a swap and ask which one to include.
Please, file an enhancement into bugzilla. ....
There is another thread "Partition selection openSUSE (install)" that is discussing this. Right now I would make only one screen out of two that experienced user has to go before it comes to expert partitioning. Later we can discuss what is the best way to handle multiple partitions. Right now the safe way would be to ask the question instead to give proposal if it is not clear from partitions. Is above OK to go as enhancement request? -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (9)
-
Andreas Hanke -
Andreas Jaeger -
Boyd Lynn Gerber -
Christian Boltz -
Hartmut Meyer -
Rajko M -
Robert Schiele -
Stanislav Visnovsky -
Warren Stockton