Re: [opensuse] Ping SUSE KDE Users - Nokia to buy Trolltech
On Monday 28 January 2008 09:12:51 am PerfectReign wrote: http://trolltech.com/company/newsroom/announcements/press.2008-01-28.460571 8236 Interesting news about this. Not sure if openSUSE will be affected at all, but I wouldn't be surprised if they change the licensing in some way. They've already said they intend to maintain the dual-license strategy, and that they intend to permit Trolltech to operate in much it's current structure, rather than be absorbed into the Nokia fold. They intend to leverage Qt as cross-platform framework across desktop and mobile devices, and they've stated that they'll be further investing in KDE as well. Nokia is an organization that does not shy away from investing resources in RD, even if they occassionally stumble on their go-to-market strategies. Obviously it's too soon to see how things will shakeout, the deal hasn't even gone through yet, but I think it's a good thing for desktop linux in general, for KDE specifically, and hence openSUSE. Just my two pennies. Cheers, KV -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse] Profile Management: How to switch automatically ?
Using the profile-manager app, when I switch profiles (I have two configured), it scans the resources etc. in one window, and then pops up another window to list resources that have changed (asking for drop/save etc.). However, if I have no resources that have changed, is there a way to have the profile switch automatically without waiting for me to click Switch on the empty confirmation window ? I just want to pick a profile and have it switch, rather than having to wait a few seconds for a couple of windows to pop up and then have to confirm the switch. Couldn't find anything in the docs to help... Thanks, KV -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse] Documentation of suspend infrastructure ?
Here's my problem, openSUSE 10.3 will not suspend my laptop when I close the lid. But if I issue an echo mem /sys/power/state, it suspends perfectly. This seems to be an issue I run into with openSUSE that gets worse with each successive version. Having used four different laptops since 9.3, all of which are capable of suspending in linux, I have had to work harder and harder to make suspend work on a laptop that will normally suspend (ie. in other distros). In the past, I would simply use ACPI scripts to suspend on lid close, then I had to start working around the improved infrastructure, hacking scripts etc. With 10.3, I'm at a loss. s2ram won't suspend regardless of the settings I use, and even disabling all of the scripts in /usr/lib/pm-utils doesn't help. I close my lid in KDE and it doesn't suspend, when I open it back up, there's an error message about being unable to suspend. I can appreciate the effort the devs put into making suspend work for laptops that may not otherwise suspend well, but it's frustrating when you know your laptop suspends well, but openSUSE prevents it, and you can't find why. /var/log/pm-suspend.log doesn't help, either. It seems like it suspended correctly. Furthermore, I know from participation in the forums that users with 10.3 have found suspend to be broken, although it worked in 10.2. We try and coach them, but there's only so much we can do... ;) What's the relation between kpowersave and s2ram/pm-utils ? Were there any major changes in 10.3 that could have broken the way the built-in suspend infrastructure works? And can I disable openSUSE from intercepting acpi calls, and just go back to running a script on lid close? Making matters worse, *buntu suspends properly when I close my lid, so I'm not sure what we've done differently. Anyways, just wondering if there's any documentation on this kind of thing. I've worked through the scripts, and gone through the wiki page etc., and it's really little help. So, help ? If I'm missing something obvious, I'll gladly accept a slap to the head. But this is becoming frustrating. My laptop has succeeded with 16 days of uptime since my last boot, by frequently suspending via echo mem ... at least 4 times a day, so stability is not an issue, then what do I need to do to get it working natively ? Thanks in advance, KV -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] suggested work around for zypper/libzypp
On Thursday 04 October 2007 12:01:47 am Cristian Rodriguez wrote: that is called transaction, I suspect that there is a good reason why it is not implemented the way you suggest. Ok, but what is the good reason? I agree that Smart is not a good model to follow due to the weaknesses in package resolution (particularly for multi-arch), but what is wrong with downloading all packages prior to installing? Frankly, in my previous experiences with factory testing over the last few versions, I have had a couple of cases where Yast crapped out during and update-all, being unable to install certain packages, and I wound up with a partially broken system after that required some sleeve-rolling-up to resolve. Nothing I would have opened a ticket for, since mirror synchronicity is sometimes a crapshoot, but frustrating none the less since it could have been avoided. I don't buy the disk space argument, that is easy enough to pre-determine before an upgrade, so I'm not sure why Yast doesn't operate this way. Really, it seems to make sense... Download all the packages into a cache, and then install them. That way if the download is interrupted (or mirrors are out of synch), the download can be resumed after, and the package upgrades won't happen until all of the packages are actually available locally. Just my 2c... Cheers, KV - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Optimizing the package manager
The biggest ? is about operation time. This cleanup also takes lot of time and is cpu and IO intensive. The right moment to do it is after heavy database writting, that is refresh. Cron job also was suggested as an idea. But consideer the cron job too random about when to do it, and also problematic f it start working when you are using YaST or the applet is checking for updates (it is safe, but you will get a lock message). Our current idea is to do it on refresh but using a time threshold. And making it configurable of course. More ideas are welcome. Is it safe to assume the cleanup intensity is dependent upon the level of fragmentation and time between cleanups? Just a thought, but would it maybe make sense to add the cleanup process as a SuSEconfig function, to run after package installation? Not that we should really strive to make SuSEconfig take even longer than it does already, but users are already conditioned to waiting for that process to run after Yast completes, they'd have a visual indication as to what is occurring, and if it runs regularly then would the cleanup procedure be quicker and less intense? Power users could of course disable it or run it at the time of their choosing, but maybe as a default setting it may not be too much of a load. Cheers, KV - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] Optimizing the package manager
Saw this brilliant post from Marcus Meissner about speeding up the package management stack (link: http://marcusmeissner.livejournal.com/13428.html ) I tried this myself, and saw a dramatic improvement. I've used openSUSE 10.3 since Alpha 5 or so, and I guess all the refreshes of factory and KDE4 cluttered the cache files, because when I ran the steps above it pretty much cut my file sizes in half and Yast package management once again ran as fast as when I initially installed 10.3. I also posted it on suseforums.net for feedback, and it seems to be positive. I understand that factory refreshes place a non-standard load on the package manager, and that most users of 10.3 Final will not be placing as high a load on the package manager, but if this addresses a flaw that is intrinsic to the way zypper and rpm operate, is it worth maybe creating a standard script via cron job that cleans the package manager on a regular basis (weekly, monthly, whatever) ? I'm really, really impressed with the improvements to package management for 10.3, and I think the vast majority of existing users will be as well. I'm just wondering if we can cut down potential problems in the default install, without relying on pointing to a page in the wiki for de-cluttering the package manager after time ? Maybe I'm missing something and this won't wind up being an issue at all, but my own experience and the feedback I've received indicates otherwise. Is this something that will already happen, or is it worth opening a feature request for? Cheers, KV - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Re: Changes with boot/init for 10.3 ? Kernel locks in 10.3, not in 10.2 ?
On Wednesday 15 August 2007 02:23:05 am Warren Stockton wrote: problem is). Try setting PROMPT_FOR_CONFIRM=yes in /etc/sysconfig/boot. You might want to set CONFIRM_PROMPT_TIMEOUT to something longer than 5 seconds for the first couple of boots. I had similar problems on a HP dv6400 with some of the 10.3alpha kernels. In my case it turned out to be /etc/init.d/boot.clock and I could lock the system at will by running hwclock --systohc or hwclock --hctosys (I don't have the problem on the current 10.3beta1 kernel and could never quite nail down the root cause when I was seeing the problem on earlier kernels.) Thanks for the pointer, that worked but not for the reasons I expected. Once I set PROMPT_FOR_CONFIRM, I was able to step through the service startup and boot properly with both the -default kernel and my own custom kernel. I didn't need to use noapic. However, booting without PROMPT_FOR_CONFIRM and without noapic produces a total lock that occurs at some point between .localfs and .udev-retry, but there are no error messages thrown and nothing indicated in the logs that would point to where the issue is. Booting with noapic and without PROMPT_FOR_CONFIRM also allows a normal boot, though with the stability issues my system experiences with noapic. Bizarre. The only thing I can think is that the parallel booting of services is somehow causing an error condition in the kernel that doesn't occur when boot prompting forces a delay between service starts, or something along those lines? I'll do a round of trial and error, disabling each boot.xxx service one by one to see if I can narrow it down, and maybe disabling parallel services as well. As far as the issue with the clock, I do remember running into that with earlier kernels, I think it first cropped up in 2.6.20, there was some change made that involved acpi, the clock and hpet or something along those lines; I remember eliminating the problem by judiciously tweaking my .config settings, but the problem seemed to have disappeared for me in recent kernels. Any other pointers appreciated... Thanks, KV - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Re: Changes with boot/init for 10.3 ? Kernel locks in 10.3, not in 10.2 ?
On Wednesday 15 August 2007 09:10:45 pm Rajko M. wrote: On Wednesday 15 August 2007 12:54, Kevin Valko wrote: and maybe disabling parallel services as well. I would start with that. Than you have better chance to find service that makes trouble. Disabling parallel services did allow the system to boot normally without requiring interactive confirmations, so there is definitely a conflict happening somewhere with the boot services running in parallel. Unfortunately I'm not sure which one, I tried disabling a number of them individually but the boot still hard-locked when parallel services were enabled, I guess I can try to change the S/K sequences in boot.d, to see if grouping the services (the culprit lies in S12) instead of all together can point out the issue. G. On the plus side, disabling parallel loading didn't have a too significant impact on my boot time, it's still more or less in line with what I had in 10.2, so it's hardly the end of the world, but it is kind of a drag since faster booting is one of the significant improvements for 10.3. Cheers, KV - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] Changes with boot/init for 10.3 ? Kernel locks in 10.3, not in 10.2 ?
Strange issue, but I've been running into problems with 10.3 since updating to beta 1 from 10.2. The kernel included on the install disc will not boot, it locks up at a random point but within 10-15 seconds after selecting install, although the safe kernel works and I managed to install. The system would not boot with the 10.3 B1 kernel unless I used kernel parameters (noapic etc.) which leads to a host of stability problems with my laptop. However, I was previously using 2.6.22 under 10.2 with no problems. Booted fine without requiring kernel parameters. I tried booting 10.3 B1 with that same kernel from 10.2 (since it still existed from my upgrade), and it would freeze 15-20s in, unless I used noapic. I even recompiled that same kernel using the same config file under 10.3, and the same problem exists. Downloaded and compiled 2.6.22.2 and ran into the same problem. Freezes during boot, works with noapic. I'm befuddled as to why this is an issue in 10.3 and not in 10.2. I suspect, but am not sure, that my issues are somehow related to the new modular mkinit process, it's more or less the only difference I can find in my boot logs as compared to 10.2. The lockups occur almost immediately after all the various xxx.sh scripts start running, but not always at the same point (which makes it harder to figure out where the problem is). It could be there's a fault with my hardware and kernel incompatibility that simply never came to light with 10.2 and only with whatever 10.3 does differently, but I want to track it down. I had similar issues in 10.2 initially that were related to 2.6.18.2 not supporting my hardware properly, but the issues more or less disappared with 2.6.20 and I was kernel-parameter free. Now I'm back to square one. Is there any source for docs on the specific changes made to mkinitrd for 10.3, as in, how to configure with various features and scripts are activated for boot? I went through the man docs, and there is info on how to enable additional settings (modules, features) but nothing on how to prevent things from being enabled, or whether there is a config file somewhere to control it all? Are there any other things that changed with the boot process I may have overlooked that could cause a previously hidden kernel problem to appear, when it remained dormant in 10.2? I'd like to roll up my sleeves (within reason ;) )and figure out what's going on, maybe by process of trial-and-error with poking and peeking various things, but am not sure where to start in this case. Sorry if this is a convoluted message, I'm not comfortable opening a bug report because I'm not sure I can reliably articulate where the actual problem is, so I'm looking for some diagnostic help before I do that. For reference's sake, the system is an HP dv9000 laptop with an AMD x2 1.8G and nvidia MCP51 chipset. Cheers, Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
