May 2007 - openSUSE Users - openSUSE Mailing Lists

[opensuse] unable to shutdown machine: does not shut down but resumes immediately
by Julien Michielsen 14 May '07

14 May '07

I'd like to shutdown my machine and use the suspend fascility so that my machine restarts faster and continues where I was before shutting down my machine. However, when I click the cameleon-icon, and then choose Leave (opening the choises Shutdown, Restart, Suspend to Disk and Suspend to Ram) and subsequently "Suspend to Disk". This only gives me a short message like "preparing to hibernate", and then immediately restarts like nothing happened. I would like to shutdown the machine, however. Lines I added to /etc/suspend.conf: HIBERNATE_MODE=shutdown shutdown method=platform One line I modified in /etc/pm/config: HIBERNATE_METHOD={userspace,kernel} but this did not improve the shutdown at all: the machine briefly shows "preparing to hybernate", goes black, and does not shut down but shows resuming . . . and restarts where it was. Is it not possible to suspend for a shutdown, and restart the next day? Thanks -- Julien Michielsen -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

3 2

Re: [opensuse] The Leopard Shows its Spots
by Randall R Schulz 14 May '07

14 May '07

Jerry, I am going to assume you didn't mean to reply to me directly (since we don't cotton to that 'round these parts) and quote your reply back to the list. On Monday 14 May 2007 12:25, Jerry Houston wrote: > Randall R Schulz wrote: > > It's not well reasoned, though, is it? First of all, the claim is > > that patents were infringed upon, not that source code was stolen. > > Patents describe concepts. Code is a reduction to practice. Bugs > > are introduced in the reduction to practice, while they're not an > > aspect of the essential concept. > > Patents are _supposed_ to be based on *processes*. There are process patents. There are device patents. And now there are software patents. Like it or not, and I most certainly do not, it's currently the law here (the U.S.) and elsewhere, and until that's changed, we're stuck in the morasse they create. > Much of what's been patented in recent years is based on concepts, > which is part of the problem. That's not the problem. Everything that works is based on a concept, after all. Even when you don't understand the principle of operation (rare or non-existent in software, I'd say), those principles exist. No, The problem is that patents are being granted for algorithms (many of them long part of common practice and common knowledge among software practitioners), loosely defined and vague "business processes" and such breathtaking innovations as "one-click shopping." Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

2 1

[opensuse] Build Service Index or Search?
by Joe Morris (NTM) 14 May '07

14 May '07

Since the Build Service has become such a wealth of packages, is there any way to search for a package there? I realize there is individual indexes for a particular version for adding as a Yast source, but there are a number of times I have wondered if a certain package was available, but searching through every directory and subdirectory is a daunting task. Just wondering if there already exists such a thing, which I think would be a very helpful feature. -- Joe Morris Registered Linux user 231871 running openSUSE 10.2 x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

7 11

[opensuse] Yast Update
by susemail 14 May '07

14 May '07

I ran Yast Update today and rebooted. Now I get these error messages: BIOS EDD facility v0.16 2004-Jun-25, 0 devices found EDD information not available. Loading edd Loading fan FATAL: Error inserting fan (lib/modules/2.6.18.8-0.3-default/kernel/ drivers/acpi/fan.ko: No such device Loading jbd Loading mbcache Loading ext3 Waiting for device /dev/sda1 to appear:..............not found-- exiting to /bin/sh Sh: no job control in this shell $ Everything worked fine before this update. What can I do to correct this? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

4 3

[opensuse] Hans Reiser
by riccardo35＠gmail.com 14 May '07

14 May '07

http://blog.wired.com/27bstroke6/2007/05/bizzare_turn_in.html ..................... -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

6 8

[opensuse] Hans Reiser
by riccardo35＠gmail.com 14 May '07

14 May '07

http://crimeblog.us/?p=403 .............................................. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

1 0

Re: [opensuse] Why are Novell guys closing perfectly valid bugs as WONTFIX due to their laziness ?
by Stefan Hundhammer 14 May '07

14 May '07

[Sorry for the disturbed threading, don't have the original mail at hand with proper headers with msg ID etc. to reply to] On 12 May 2007 10:14:25, Alexey Eremenko wrote: > Why are Novell guys closing perfectly valid bugs as WONTFIX ? This question, by itself, is perfectly valid. Explanation follows. The subject line, however, is offensive at least in its closing part: "due to their laziness" is not acceptable. More about that below. First let me explain the WONTFIX situation. https://bugzilla.novell.com/page.cgi?id=fields.html#resolution explains WONTFIX only in very short terms: "WONTFIX The problem described is a bug which will never be fixed." That means that WONTFIX acknowledges that a bug as reported is indeed a valid bug. But it also says that it will not be fixed: Not in the near future (that would be status ACCEPTED), not in some future release (that would be LATER), never. It means that whoever is responsible for the piece of software against which the bug was reported has examined the situation and evaluated possible approaches to fix the problem. But the conclusion of that process was that the bug will not be fixed. Of course, this is unsatisfactory for a user who took the trouble to make a bug report. Agreed. But there are also other considerations to take into account. In the general case (not being specific about the bug report you quoted later in your posting), that can be: (1) There is no solution at all. Even though this happens only rarely, it can happen. Typically, this is the result of a previous conscious decision (in the design or implementation of the software) in which the lesser of two evils had been chosen, and the trade-off that had been taken back then is what was reported as the bug that got closed as WONTFIX. (2) The problem could be fixed, but the cost for the fix (the amount of work involved) would be enormous. It would be an economic nightmare to do the fix. This would really be a status TOOEXPENSIVE that Bugzilla does not provide. In an ideal world, no cost whatsoever would be too expensive. But we all live in a less-than-ideal world, and so economy has to be taken into consideration. This is not only important for us (SUSE/Novell) as the distribution makers (or in general for the company who has to pay for the development hours), it is also important for the users: Since there is only a finite number of developers and thus of development hours, hours spent on fixing a bug cannot be spent on developing something new or even just on fixing other bugs that may be more important. (3) The problem could be fixed, but the fix would make the software much more complex and thus much less maintainable and possibly also much less stable. This is partly no. (2) again, partly another aspect users benefit a lot from: Software stability. You don't want to compromise stability for issues that are not really important. (4) The problem is in another piece of software this software depends on, but that other software is being developed and maintained elsewhere. The fix has to be done upstream. Now we as the distribution makers do make some fixes in software that is developed elsewhere. But that is limited to minor fixes. It clearly does not involve major rewrites of upstream software. Those rewrites would go to waste with the next upstream release. Sometimes we do even that and send the patch upstream, hoping that it will be accepted and incorporated into the next upstream release. But this requires that the upstream developers are very cooperative, and that they are not already working on another solution our fix would be incompatible to. Whichever reasoning might be behind resolving a bug as WONTFIX, it deserves a clear explanation the bug reporter can understand. This is what we owe to somebody who goes through the trouble of reporting a bug. This is our moral obligation to the bug reporter. > They should stop being lazy all the day. ... > The lazy number one is: marcio ferreira and Stefan Hundhammer This I take offense of. This is very personal and unjustified. You are attacking Marco Ferreira (another community member, by the way, not a SUSE or Novell employee) personally. Worse, not only are you doing that in a public forum, you are also doing that in a forum different from the original discussion (the bug report) so the involved people might never even get to know that they were attacked. Now you may not be aware of some of the things I tried to explain above, but calling people you don't even know lazy is clearly going over the top. > That is not a feature-request but a bug. We were fully aware of that and treated it accordingly. > link: > https://bugzilla.novell.com/show_bug.cgi?id=264716 The bug report contains an explanation why the bug was closed as WONTFIX. I considered the explanation adequate: https://bugzilla.novell.com/show_bug.cgi?id=264716#c11 "The Qt-based YasT2 control center is a very basic application that uses the QIconView widget for those icons. y2cc doesn't do any fancy stuff. It might very well be that QIconView simply doesn't do that any better." Maybe I was wrong to consider that explanation adequate. I thought it contained the necessary information: - The YaST2 Qt control center (the software in question) does not do the rendering itself. Rather, it uses QIconView which is part of the Qt (3.x) libs. - The problem is outside the scope of that application. It is a problem of the Qt (3.x) libs. - While we do make some fixes in the Qt libs, that kind of fix is beyond our scope. The problem would have to be fixed upstream by TrollTech (the makers of Qt). So this would be a case of reasoning (4) above. What I did not explicitly mention (but might have in hindsight) is that we will migrate YaST2-Qt and thus the YaST2 Qt control center to Qt-4 in the near future, so spending a lot of development hours and thus money on fixing that issue in Qt-3 would very likely be a waste anyway. > What's worse is that they tell me something like: "If you do that > again I will formally ask a certain account of bugzilla to be > canceled." > > How am I supposed it eat that as a community-member ? I would suggest to ask your fellow community member who wrote this. Hint: Bugzilla uses tool tips for the E-mail addresses. If you hover your mouse pointer over the name of a bug commenter, the status line of your browser will give you the full E-mail address (checked with Konqueror and Firefox). You need to be logged in to Bugzilla for this to work, though. In this particular case, that commment came from a gmail.com address, not from a novell.com or suse.de address. As for others who raised the question if we get paid by the number of bug reports we get rid of: No. That would obviously not make any sense, too. But Bugzilla is an important tool for us. So it makes sense for us to resolve issues that can easily be resolved before they clutter our list of active bugs too much. It's also a question of honesty. While we could accumulate a large number of bugs and pretend that we will fix them at some point, wouldn't you rather have us be honest and clearly say if an issue does not have the slightest chance of getting fixed in a forseeable time frame? Of course such honesty can be brutal sometimes. If somebody has a "favourite issue" to get fixed, of course it is disappointing to hear that it has been given consideration and decided against. On the plus side, you might even see it as us defending the one thing we put a lot of our life blood into: Our distribution, no matter if it's the business products or the community project. We have to think economically. If one day the money stops rolling in because we distributed our available development hours unwisely on minor issues, nobody will benefit from those minor issues to be fixed. Rather, the distribution will be dead. Like it or not, we can only put so much time into every one of our release. We constantly have to make decisions. Some of them may result in a less-than-perfect product, but a product that remains alive and kicking, a product that gets released on a regular release cycle. Some users may not like some of the decisions we make. That's life. You just can't be everybody's darling. ;-) Kind regards -- Stefan Hundhammer <sh(a)suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

3 3

[opensuse] Where is perl-YAML?
by Josef Wolf 14 May '07

14 May '07

Hello, In 10.2, I'm missing the perl-YAML package. It was included in 10.1, but seems not to be part of 10.2 anymore. Is there any reason why it was removed and where to find it? Thanks, -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

4 6

[opensuse] How do new releases get into the factory?
by Greg Freemyer 14 May '07

14 May '07

All, I have pulled some factory rpms, but I have no idea how the opensuse team/community becomes aware that new releases are available and that a new rpm should be made available. Specifically, rdiff-backup did a release in the last few days that has a feature I would like to utilize. I'm familiar enough with the process to just pull it down for myself, but I thought it would be better if I could somehow trigger the build service to make it available for all. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

2 2

[opensuse] sound error
by William Biggs 14 May '07

14 May '07

Thank you for all your help I got it to work I had it under the user -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse+help(a)opensuse.org

1 0