May 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306436] Filter for Leaf Packages in Software Management
by fate_noreply＠suse.de 15 May '09

15 May '09

Feature changed by: Rémy Marquis (Spyhawk) Feature #306436, revision 3 Title: Filter for Leaf Packages in Software Management openSUSE-11.2: New Priority Requester: Mandatory openSUSE-11.3: New Priority Requester: Mandatory Requested by: Berthold Gunreben (azouhr) Description: I'd like to see a new Filter in the Software Management of YaST that enables the user to see "Leaf" packages that do not provide functionality needed by other packages. This would make it easier for customers to remove unneeded packages from the system. + Discussion: + #1: Rémy Marquis (spyhawk) (2009-05-15 16:50:20) + Strongly related to Feature 300758 (orphaned packages). To be marked as + a duplicate. + See https://features.opensuse.org/300758 + -- openSUSE Feature: https://features.opensuse.org/306436

1 0

[openFATE 306354] OSC under Windows
by fate_noreply＠suse.de 15 May '09

15 May '09

Feature added by: andrea florio (anubisg1) Feature #306354, revision 1, last change by Title: OSC under Windows Buildservice: Unconfirmed Priority Requester: Important Requested by: andrea florio (anubisg1) Description: i think that port OSC under windows will be really usefull, everybody know what osc is, but use it under windows can allow me and lots of developer/packager to work on packages even if they are running windows for any reason -- openSUSE Feature: https://features.opensuse.org/306354

1 8

[openFATE 302485] sync GPT and MBR on MacBook (mactel)
by fate_noreply＠suse.de 13 May '09

13 May '09

Feature changed by: Lars Vogdt (lrupp) Feature #302485, revision 32 Title: sync GPT and MBR on MacBook (mactel) openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-10-01 12:11:18 reject reason: not done from what I heared Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-04-28 09:46:04 reject reason: lacking parted maintainer for the moment Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Done Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Done Priority Requester: Mandatory Requested by: Ruediger Oertel (oertel) Description: on multiboot setups on MacBooks and other mactel machines, using a combination of GPT and MBR is pretty common (and necessary if you either want to use grub or are also using Windows) for installation on these machines we need to offer a way to sync the GPT to the MBR whenever a change to the GPT is made. There exists a patch for parted to do just this (see bugzilla#220839) and also the sources of refit (refit.sourceforge.net, tool gptsync). Relations: - GPT partitioning and boot support (feature/id: 303026) - fully support disks with GPT (feature/id: 303924) Discussion: #1: Stephan Kulow (coolo) (2007-08-01 12:37:33) sounds like a dataloss we should fix for 10.3 too #2: Edith Parzefall (emapedl) (2007-08-01 17:42:46) We need to find out more about what actually needs to be done, before we can consider making an attempt for 10.3 despite the approaching deadline. #3: Edith Parzefall (emapedl) (2007-08-07 11:53:32) There's not enough time left, please reject for 10.3. #4: Ruediger Oertel (oertel) (2007-11-06 12:29:36) for reference, the patch for parted is in bug#220839. This patch adds the method "map_gpt_to_msdos" to parted and was written by Olaf Hering and discussed on the parted mailing list in May 2007. #5: Duncan Mac-Vicar (dmacvicar) (2008-02-04 21:29:52) Olaf, you wrote the patch, can you please describe us what is exactly needed so YaST makes this kind of configuration to work? There is little knowledge about this situation and we imagine adding the patch to parted is not the only required step. Some additional code in YaST and while setting up the bootloader might be required. Do you know about it? #6: Olaf Hering (olh) (2008-02-18 10:04:25) (reply to #5) There are comments in the patch. Once the GPT partitioning is done, map one GPT partition to a primary msdos partition. yast2-storage knows what the boot partition is, so it can force the mapping. #7: Arvin Schnell (aschnell) (2008-04-03 17:11:26) Duncan asked me to summarise the task for implementation: 1) Include parted patch "parted.msdos-on-gpt.patch". Thomas saw the risk of breaking parted by this. Issue for parted maintainer (we have none). 2) Add new calls to parted to establish the mapping from GPT to MSDOS disk labels. Issue for yast2-bootloader and/or yast2-storage. 3) Fix bootloader config to not call "parted ... boot on" when it's already on. Should fix the update problem Rudi has. Issue for yast2- bootloader. AFAIS not required with patched parted. #8: Duncan Mac-Vicar (dmacvicar) (2008-04-14 11:43:17) Coolo, points 1 and 3 call for reject until bootloader situation and parted one is better. #9: Joachim Plack (jplack) (2008-04-28 12:30:48) michl@ : AFAIK The MacBooks are to date not handled as a supported platform. But they should be last but not least due to there pretty wide spread of that thingy. Please check, define and prioritize. Thanks. BTW there are some booting issues involved #10: Michael Loeffler (sprudel24) (2008-04-28 13:36:54) (reply to #9) That's a clear "nice to have" feature. Needed ressources and involved risks need to be low. #11: Stephan Kulow (coolo) (2008-06-12 12:39:54) (reply to #10) I'm not so sure about this. Depending on what market you look at, you get a market share of 10 - 50 percentage. I didn't fail to notice that Saturn Fürth's laptop departement is basically built around macbooks. #12: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:21:19) Please reject for 11.0. All resources allocated with mandatory features already. #13: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:46:29) (reply to #12) meant SLE11/openSUSE11.1 #14: Alexander Graf (algraf) (2008-08-22 19:54:25) (reply to #13) For openSUSE 11.1 / SLES11 it's done already. I checked in a patch for parted a while ago. #15: Stephan Kulow (coolo) (2009-04-22 14:22:43) (reply to #14) opening to openfate to have a link + #16: Lars Vogdt (lrupp) (2009-05-13 12:43:12) (reply to #14) + For me it doesn't look like "done already". + I've a MacBook Pro here and tried to install openSUSE 11.1 without + success. FYI: I'm using rEFIt as "bootloader" here - and after each + installation, rEFit tells me that the MBR and GPT is out of sync and + can't be repared. + With the older openSUSE (10.3) it works with this workaround: + http://en.opensuse.org/Installation_on_MacBook_Pro_Intel_(x86) <-- grub + is not installed + Sadly I need the MacBook for my work, but if you can't find another + one, I can run a backup and reproduce my problems for you. -- openSUSE Feature: https://features.opensuse.org/302485

1 0

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: andrea florio (anubisg1) Feature #305296, revision 80 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #26: Peter Nixon (peternixon) (2009-03-11 20:39:01) (reply to #3) +1 #29: Pedro Veloso (pedrodh) (2009-04-01 22:18:05) (reply to #26) Totally agree #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to #17) Hm, as it seems I cannot open such a request. Wonderful! So perhaps somebody has read this discussion and might be so kind to at least evaluate the request and "perhaps" might open a new feature request concerning the replacement of beagle by Tracker (which is a Gnome Desktop search, but since KDE has already its own Desktop search this should not be that problematic... I hope) And before somebody asks: no I will not file a feature request via bug tracking system. Those usually take weeks or even months before they are answered/evaluated/discussed etc... #19: Federico Lucifredi (flucifredi) (2009-02-19 16:52:12) (reply to #18) Hello Sebastian - I do not take the thread as being "against desktop search", which is a great feature, or against Beagle, which I personally run. The decision is only to have Beagle not be running by default out of the box, but to have it installed and ready. The first time a search is performed, we ask. Users who want desktop search select to run it, and those who are more "frugal" in terms of CPU do not. I am running a 3 year old laptop, and Beagle is running just fine for me. I suspect that's the case for a lot of people. But it is still a good idea to ask for a choice. #20: Eric Springer (erikina) (2009-02-22 03:03:55) (reply to #17) 100% agree. I think tracker/strigi make wonderful replacements. :) #22: andrea florio (anubisg1) (2009-02-25 00:40:51) (reply to #20) indeed... beagle is to heavy, traker instead, is simply wonderful! #23: Barbara Hudson (barbie_h) (2009-03-04 02:22:21) (reply to #15) I was going to vote in favour of the request, because I've been bitten by beagle bringing machines to a crawl many times, but one thing I've noticed is that, as people move to dual / quad -core machines, it's no longer a big issue. I'm not saying ignore the memory and resource problems - just that even laptops nowadays can run plasma and beagle and still feel responsive. The current system, where it notifies you when it does the initial indexing, is a lot better than the computer slowing to a crawl on a fresh install and people wondering why openSUSE is soooo slow. #21: Stanislav Visnovsky (visnov) (2009-02-24 09:10:56) Coolo, I believe this should be done via patterns. #24: Stephan Kulow (coolo) (2009-03-04 11:52:23) (reply to #21) having a desktop search easy to enable sounds like a good to have feature, so I wouldn't simply remove the package from install. But it doesn't make sense on a KDE4 desktop (and it's not there in 11.1 afaik) and it doesn't have to be running by default for GNOME either. But this is something for the beagle maintainers to decide. #25: Stephan Kulow (coolo) (2009-03-04 11:53:33) (reply to #24) that is: it should be off by default (seeing all the votes). But if it's worth to make it easier to turn it on than it is, I leave to those that know. But the solution to enable it, should be within the desktop. #27: Jan Engelhardt (jengelh) (2009-03-16 18:03:00) Less than "easy way to disable beagle completey during installation" it should even be "disable beagle by default", thank you. #28: Marcel Müller (open_assistant) (2009-03-16 20:32:45) great idea, especially to my slowly pc #30: Gabriel Stein (gabrielstein) (2009-04-03 21:15:44) Totally Agree. I just post on my blog, and I will pay 5 pints of Guinness to the great developer which will do that amazing thing. #31: john andersen (jsamyth) (2009-04-16 20:22:51) I agree Beagle should be an optional item, not installed by default.   There, I've said it.   But an alternative might be to install it and restrict it't indexing BY DEFAULT to the user's home directory, (and perhaps the user's mail spool), and hava a configuration window that allows adding additional directories. That is a feature that might make it more palletable.  But realistically, when this many people arrive at a Future Feature site begging and pleading for a package to dropped from a normal installation you should assume there are some serious flaws with that package.  This site should be about new and improved features we would all like to see, but instead this thread is focused on something that has been rammed down our throats for way too many releases, and which has historically been difficult to remove.   Side issue: Unless you are a Linux Developer there is no point in having it index the entire hard drive.  Your average user has no need of these areas, and experienced users already know where things are, so a generalized indexer that searches the entire disk is a solution looking for a problem. #32: jean-christophe baptiste (phocean) (2009-04-27 11:28:48) Ok for those who want to get an easy way to disable Beagle. But it should be activated by default. I am using Beagle intensively (on Gnome) and I have never got a problem with it. It just rocks and a huge time saver to me. Maybe my hardware is just not obsolete (Core 2 duo laptop)... I think it is the kind of killer app good to show off and that can bring more new users. + #33: andrea florio (anubisg1) (2009-05-12 20:04:51) (reply to #32) + you are luky then.. beagle on my pc make them very very slower, it + should be disabled by default, if you need it, then you insta/activate + it -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305268] Refactor bootloader UI
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305268, revision 9 Title: Refactor bootloader UI - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Jiri Srain (jsrain) Description: In order to simplify maintenance, allow to fix some bugs and also use more flexibility of YaST UI, the user interface of the bootloader module should be rewritten to YCP instead of using generator with limited possibilities. Discussion: #2: Federico Lucifredi (flucifredi) (2009-01-26 20:45:53) prioritizing cleanup task as per plan. #3: Stanislav Visnovsky (visnov) (2009-02-02 13:11:26) Jiri, please, document the planned changes and provide a link for the feature. #7: Jozef Uhliarik (juhliarik) (2009-05-12 16:46:32) Refactoring yast2-bootloader UI is done. It is possible that it will be little modified later but the basic goal is done. -- openSUSE Feature: https://features.opensuse.org/305268

1 0

[openFATE 305268] Refactor bootloader UI
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305268, revision 8 Title: Refactor bootloader UI openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Jiri Srain (jsrain) Description: In order to simplify maintenance, allow to fix some bugs and also use more flexibility of YaST UI, the user interface of the bootloader module should be rewritten to YCP instead of using generator with limited possibilities. Discussion: #2: Federico Lucifredi (flucifredi) (2009-01-26 20:45:53) prioritizing cleanup task as per plan. #3: Stanislav Visnovsky (visnov) (2009-02-02 13:11:26) Jiri, please, document the planned changes and provide a link for the feature. + #7: Jozef Uhliarik (juhliarik) (2009-05-12 16:46:32) + Refactoring yast2-bootloader UI is done. It is possible that it will be + little modified later but the basic goal is done. -- openSUSE Feature: https://features.opensuse.org/305268

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Jan Kara (jankara) Feature #305168, revision 23 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 Discussion: #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) Bug #461829 is not requesting breaking POSIX semantics by default! relatime should replace noatime option in the mount options part of partioner tool, especially now it has been improved to update atime on file access if it's older than 24 hours. Standards are important, and LRU file caches cannot be relied on if noatime usage is common, or if poor backup software touches atimes, when reading files. #2: Sven Burmeister (rabauke) (2009-01-23 01:09:47) 11.1 is out and 11.2 getting started. Did anyone hear of ubuntu suffering from using relatime by default? If not, it seems likely that there are little to none issues. #3: Stephan Kulow (coolo) (2009-05-08 16:51:21) Matthias, I would think the easiest solution is replacing the current checkbox "use noatime" with "use relatime" and make it default (possibly per product). atime is a major pain for many systems where powersave and co are affected. #4: Matthias Eckermann (mge1512) (2009-05-11 15:52:11) (reply to #3) I am not perfectly happy, as a system crash could invalide the "atime"s with "relatime" switched on; looking for supporting information though, it seems, the broader Linux community is in favour of "relatime" (with remarkable exceptions); thus I propose: * introduce "relatime" as an independend parameter * keep the "noatime" checkbox in YaST * make "relatime" default on SSDs automatically * introduce a generic switch in YaST "defaultrelatime", which can be switched on/off per product * make "relatime" default "on" for the openSUSE product Does that help? #5: Jan Kara (jankara) (2009-05-11 16:33:11) This is a bit separate to how it will all look in Yast but I wanted to point out that in current Linus's tree (going to be 2.6.30) is a patch which changes kernel's default to 'relatime'. So unless we change something, all filesystems on this or newer kernel are going to be mounted as relatime (you have to specify 'strictatime' mount option if you really wish to keep atime). #6: Stephan Kulow (coolo) (2009-05-12 10:36:27) (reply to #5) then we can leave everything as it is actually and the feature is Done once we switch to 2.6.30 #7: Jan Kara (jankara) (2009-05-12 13:08:05) (reply to #6) Yes, the original request will be fulfilled. But I believe it would be good to have a selection in partitioner tool like: "Access time behavior: <relatime|noatime|strictatime>" anyway and make 'relatime' default. Also it is a question how to behave on update - the safest would be to add 'strictatime' to filesystems that don't have any atime setting but realistically it is probably better to ask user whether he agrees to switching to relatime and default to "yes". #9: Stephan Kulow (coolo) (2009-05-12 13:45:51) (reply to #7) completely different feature IMO and way more complex (and definitely over the top of openSUSE 11.2) #10: Duncan Mac-Vicar (dmacvicar) (2009-05-12 14:00:25) (reply to #7) Do we really need this extra options really? Is there a good usecase for it? I don't want to bring something to implementation because it is "good", "cool" or "nice to have". + #11: Jan Kara (jankara) (2009-05-12 15:50:33) (reply to #10) + User can always edit /etc/fstab by hand so strictly speaking it's not + necessary. About the usecase - there really are people who want + 'strictatime' for various reasons (well, most often they are just + afraid that something can break). From my POV that is enough for + substituting that 'noatime' checkbox we have currently with the + selection I suggested but I admit I'm not the one who'll have to + implement it ;-). + Regarding the update - silently changing the behavior of atime seems + kind of rough to users to me. At least we should warn them (release + notes?) that this is happening and that they can add 'strictatime' to + /etc/fstab if they have problems with the change. -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 306403] KOffice 2.1 in 11.2
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Stephan Binner (Beineri) Feature #306403, revision 3 Title: KOffice 2.1 in 11.2 openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Jean Cayron (jeancayron) + Developer: Stephan Binner (beineri) Description: KOffice 2.1 will be released in november 2009, at the same time than openSUSE 11.2 ( see release plan (http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.1/Release_Plan) ). Since the 2.0 will not be feature complete, it would be great for KDE4 integration to have the latest version on the official repositories (maybe do as Firefox the RC with later update). Let make the people choose their Office Suite. -- openSUSE Feature: https://features.opensuse.org/306403

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305168, revision 22 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 Discussion: #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) Bug #461829 is not requesting breaking POSIX semantics by default! relatime should replace noatime option in the mount options part of partioner tool, especially now it has been improved to update atime on file access if it's older than 24 hours. Standards are important, and LRU file caches cannot be relied on if noatime usage is common, or if poor backup software touches atimes, when reading files. #2: Sven Burmeister (rabauke) (2009-01-23 01:09:47) 11.1 is out and 11.2 getting started. Did anyone hear of ubuntu suffering from using relatime by default? If not, it seems likely that there are little to none issues. #3: Stephan Kulow (coolo) (2009-05-08 16:51:21) Matthias, I would think the easiest solution is replacing the current checkbox "use noatime" with "use relatime" and make it default (possibly per product). atime is a major pain for many systems where powersave and co are affected. #4: Matthias Eckermann (mge1512) (2009-05-11 15:52:11) (reply to #3) I am not perfectly happy, as a system crash could invalide the "atime"s with "relatime" switched on; looking for supporting information though, it seems, the broader Linux community is in favour of "relatime" (with remarkable exceptions); thus I propose: * introduce "relatime" as an independend parameter * keep the "noatime" checkbox in YaST * make "relatime" default on SSDs automatically * introduce a generic switch in YaST "defaultrelatime", which can be switched on/off per product * make "relatime" default "on" for the openSUSE product Does that help? #5: Jan Kara (jankara) (2009-05-11 16:33:11) This is a bit separate to how it will all look in Yast but I wanted to point out that in current Linus's tree (going to be 2.6.30) is a patch which changes kernel's default to 'relatime'. So unless we change something, all filesystems on this or newer kernel are going to be mounted as relatime (you have to specify 'strictatime' mount option if you really wish to keep atime). #6: Stephan Kulow (coolo) (2009-05-12 10:36:27) (reply to #5) then we can leave everything as it is actually and the feature is Done once we switch to 2.6.30 #7: Jan Kara (jankara) (2009-05-12 13:08:05) (reply to #6) Yes, the original request will be fulfilled. But I believe it would be good to have a selection in partitioner tool like: "Access time behavior: <relatime|noatime|strictatime>" anyway and make 'relatime' default. Also it is a question how to behave on update - the safest would be to add 'strictatime' to filesystems that don't have any atime setting but realistically it is probably better to ask user whether he agrees to switching to relatime and default to "yes". #9: Stephan Kulow (coolo) (2009-05-12 13:45:51) (reply to #7) completely different feature IMO and way more complex (and definitely over the top of openSUSE 11.2) + #10: Duncan Mac-Vicar (dmacvicar) (2009-05-12 14:00:25) (reply to #7) + Do we really need this extra options really? Is there a good usecase + for it? + I don't want to bring something to implementation because it is "good", + "cool" or "nice to have". -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Stephan Kulow (coolo) Feature #305168, revision 21 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 Discussion: #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) Bug #461829 is not requesting breaking POSIX semantics by default! relatime should replace noatime option in the mount options part of partioner tool, especially now it has been improved to update atime on file access if it's older than 24 hours. Standards are important, and LRU file caches cannot be relied on if noatime usage is common, or if poor backup software touches atimes, when reading files. #2: Sven Burmeister (rabauke) (2009-01-23 01:09:47) 11.1 is out and 11.2 getting started. Did anyone hear of ubuntu suffering from using relatime by default? If not, it seems likely that there are little to none issues. #3: Stephan Kulow (coolo) (2009-05-08 16:51:21) Matthias, I would think the easiest solution is replacing the current checkbox "use noatime" with "use relatime" and make it default (possibly per product). atime is a major pain for many systems where powersave and co are affected. #4: Matthias Eckermann (mge1512) (2009-05-11 15:52:11) (reply to #3) I am not perfectly happy, as a system crash could invalide the "atime"s with "relatime" switched on; looking for supporting information though, it seems, the broader Linux community is in favour of "relatime" (with remarkable exceptions); thus I propose: * introduce "relatime" as an independend parameter * keep the "noatime" checkbox in YaST * make "relatime" default on SSDs automatically * introduce a generic switch in YaST "defaultrelatime", which can be switched on/off per product * make "relatime" default "on" for the openSUSE product Does that help? #5: Jan Kara (jankara) (2009-05-11 16:33:11) This is a bit separate to how it will all look in Yast but I wanted to point out that in current Linus's tree (going to be 2.6.30) is a patch which changes kernel's default to 'relatime'. So unless we change something, all filesystems on this or newer kernel are going to be mounted as relatime (you have to specify 'strictatime' mount option if you really wish to keep atime). #6: Stephan Kulow (coolo) (2009-05-12 10:36:27) (reply to #5) then we can leave everything as it is actually and the feature is Done once we switch to 2.6.30 #7: Jan Kara (jankara) (2009-05-12 13:08:05) (reply to #6) Yes, the original request will be fulfilled. But I believe it would be good to have a selection in partitioner tool like: "Access time behavior: <relatime|noatime|strictatime>" anyway and make 'relatime' default. Also it is a question how to behave on update - the safest would be to add 'strictatime' to filesystems that don't have any atime setting but realistically it is probably better to ask user whether he agrees to switching to relatime and default to "yes". + #9: Stephan Kulow (coolo) (2009-05-12 13:45:51) (reply to #7) + completely different feature IMO and way more complex (and definitely + over the top of openSUSE 11.2) -- openSUSE Feature: https://features.opensuse.org/305168

1 0