October 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305657] finer grained PolicyKit support for Networkmanager
by fate_noreply＠suse.de 05 Oct '09

05 Oct '09

Feature changed by: Tanja Roth (ta-ro) Feature #305657, revision 42 Title: finer grained PolicyKit support for Networkmanager openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Desirable Requested by: Ludwig Nussel (lnussel) Description: NetworkManager currently only supports one PolicyKit privilege. That is whether a user is allowed to modify administrator defined connections or not. There is no way to disallow users to define their own network configurations. NetworkManager should at least support one additional PolicyKit privilege that defines whether or not users are allowed to bring their own network configuration or whether they mere are allowed to use administrator defined ones. Use Case: - disallow workers on centrally administered machines to configure different network settings - protect home users that only ever connect to a few well known nets from accidently changing their setup Discussion: #1: Matthias Nagorni (mnagorni) (2009-08-21 14:26:22) If this can be done with little effort I would be even tempted to rate it Mandatory. #2: Stefan Behlert (sbehlert) (2009-08-25 16:37:57) Alex, is there soemone on your team who could look at that? MAybe with some support form Tambet? #3: Li Bin (binli) (2009-08-26 05:58:01) I and lance wang would like to take care of it. We still don't know the requirement clearly. 1. disallow workers on centrally administered machines to configure different network settings The workers mean the users in administered machines? Does it right that when workers configure network settings it prompt they are no permission? If so I thought we could change the PolicyKit's configuration file to complete it. 2. protect home users that only ever connect to a few well known nets from accidently changing their setup How to distinguish home users from workers? Does it mean don't allow the user to configure the other users connections? #4: Ludwig Nussel (lnussel) (2009-08-26 08:40:53) (reply to #3) Currently there's only org.freedesktop.network-manager-settings.system. modify, introduce something like org.freedesktop.network-manager- settings.user.modify so NM can determine whether it should accept user settings. #16: Wang Lance (lzwang) (2009-09-25 11:26:20) (reply to #4) Hi Ludwig Nussel I have added the following policy action: org.freedesktop.network-manager-settings.user.wired.apply org.freedesktop.network-manager-settings.user.wireless.apply org.freedesktop.network-manager-settings.user.mobile.apply org.freedesktop.network-manager-settings.user.vpn.apply org.freedesktop.network-manager-settings.user.dsl.apply . NM now can determine whether it should apply the user settings to devices by type. Does the implementation meet your request? I need your feedback to determine what should to do next step. Thanks, Lance Wang #17: Ludwig Nussel (lnussel) (2009-09-25 11:58:50) (reply to #16) Sure, that's even more than I had wished for. Would it be possible to also have a separate privilege for the connection sharing thingy? In contrast to the other configurations that one also messes with iptables and starts a DHCP daemon. #5: JP Rosevear (jproseve) (2009-08-26 17:06:51) (reply to #3) My suggestion would be to look at something like the following: org. freedesktop.network-manager-settings.system.modify org.freedesktop. network-manager-settings.system.add org.freedesktop.network-manager- settings.system.delete and the same for .user - you may even want to specifically allow or disallow adding for specific network types like wired, wireless, etc. You probably also want to have the ability to enable/disable wireless in general and enable/disable networking covered. You can default all of these to the current settings, but adding these would allow more lockdown opportunities. #6: Li Bin (binli) (2009-08-31 11:22:12) Well, We'll works on this feature in this week, know about the PolicyKit and NetworkManager, write the patch if time is okay. Tambet, Do you have any idea about this feature? #7: Luis Medinas (lmedinas) (2009-08-31 18:40:51) (reply to #6) Might worth looking at NM 0.8 (git master), it supports the latest polkit-1 and it should be released before 11.2. Maybe some of this features were introduced. #8: Tambet Ingo (tambet) (2009-09-01 09:40:05) (reply to #7) NM 0.8 will not be out before 11.2, it'll be out for the next Fedora release which will happen after 11.2. Also, current git master does not have any work for this feature, it's just been converted to use the newer, incompatible polkit API. #9: Tambet Ingo (tambet) (2009-09-01 09:43:56) (reply to #6) The upstream has been planning on having similar feature for a while now, but no work has been done on it yet. I strongly suggest to have a discussion with the upstream maintainer before any work gets done, otherwise our effort might end up thrown away as soon as upstream implements it. #10: Li Bin (binli) (2009-09-01 09:14:24) Yes, I talk with the upstream today, just wait for response. You can follow it from below link. Thanks! http://mail.gnome.org/archives/networkmanager-list/2009-September/date.html #11: Stephan Kulow (coolo) (2009-09-07 13:39:17) (reply to #10) didn't see a lot of replies. #12: Li Bin (binli) (2009-09-10 05:24:05) The upstream maintainer Dan already reply this issue, and it's no user case for seperating add, modify and delete permission, and the others was agreed. Lanc wang with me work the sled11 and upstream now, we'll provide a patch in this week. #13: Wang Lance (lzwang) (2009-09-15 08:10:43) Hi I add five policy like the following : org.freedesktop.network-manager- settings.system.wired.modify org.freedesktop.network-manager-settings. system.wireless.modify org.freedesktop.network-manager-settings.system. mobile.modify org.freedesktop.network-manager-settings.system.vpn. modify org.freedesktop.network-manager-settings.system.dsl.modify. As you know there will be one policy one type. I make a patch which works. But I feel a little confused on the user settings. As the user settings are saved in the gconf, so adding someting like manager- settings.user.*.modify make no sense. As far as I know user can always edit their gconf settings. I think what should be done may be the policy that determine if the users can apply their settings to the system devices throught dbus. Given we do it like that, should the nm-applet display the user setting in the menu, when a normal user can not apply his or her settings to system devices? I think it is better that nm-applet show both system settings and user settings, and it will show error dialog if a user try to apply user settings when the user does not have the right do that. Hi Tambet, what do you think? #14: Li Bin (binli) (2009-09-17 11:18:37) (reply to #13) Tambet reply in the mailinglist, we just lock the /system/networking path in gconf and the settings can't be changed. #15: Michael Meeks (michael_meeks) (2009-09-23 16:55:40) We should also add the case mentioned in bug #522742 - to allow disabling the "Create new wireless network" functionality. This is of particular concern to the security team, and I'd like to see it addressed as part of the same work if possible. Otherwise, this looks great - thanks Li Bin :-) #18: Li Bin (binli) (2009-09-25 12:03:28) (reply to #15) Michael, I've viewed the bug#522742, it talk more about sharing, and we don't need to disable "Create new wireless network", user can add it, but when they wanna to apply it by click the connection, check org. freedesktop.network-manager-settings.user.wireless.apply permission like the Lance describe in #16. Does it okay? #19: Michael Meeks (michael_meeks) (2009-09-28 10:10:26) (reply to #18) No - connecting to a new wireless network is -very- different from sharing all your existing connections over your current wireless network; I can see why people would want to allow one and not allow the other. We should (ideally) have a different policy setting for this - if possible. Thanks + #20: Tanja Roth (ta-ro) (2009-10-05 15:01:26) + Can you please confirm what the final policy names (identifiers) are + going to be for 11.2 and what can be influenced with them? (a short + description as available from the Description field in polkit-gnome- + authorization would be sufficient). + I would like to mention this in the 11.2 docs about NetworkManager, but + so far, I only found the one policy that relates to modifying + administrator defined connections (org.freedesktop.network-manager- + settings.system.modify). From your comments above I'm not sure if the + names mentioned in #16 are the final ones for the newly added policies + (and if the list is complete). Please advise asap as the translation + deadline for this chapter is approaching. Thanks! -- openSUSE Feature: https://features.opensuse.org/305657

1 0

[openFATE 302354] Split metadata by architecture / modules
by fate_noreply＠suse.de 05 Oct '09

05 Oct '09

Feature changed by: Adrian Schröter (adrianSuSE) Feature #302354, revision 25 Title: Split metadata by architecture / modules - Buildservice: Evaluation + Buildservice: Rejected by Adrian Schröter (adriansuse) + reject date: 2009-10-05 14:22:19 + reject reason: We have seperation of architectures for all + architectures for SLE* products via the product definition. + For openSUSE the only joined trees are i586 and x86_64. Same for the + repositories rpm-md trees. This means a seperation would only give i586 + users an advantage at all. + The base tools do not support (createrepo/create_package_descr) are + also not supporting/defining such a seperation atm. + There is also no support in the downloader of YaST to download one + packages file only atm according to Michael Andres. + So, x86_64/ppc64/s390x/ia64 users would have anyway no advantage for + this feature and there would be quite some work needed. Making this for + i586 users only makes no sense IMHO. Priority Requester: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-03-28 16:28:18 reject reason: Out of resources. The speed of parsing is greatly improved, downloading is still an issue in 11.0. Priority Requester: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-11-20 19:33:01 reject reason: postponing unless engineering tells me otherwise. Priority Requester: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-04-22 11:37:36 reject reason: As discussed with Duncan: Won't gain much on openSUSE, lacking resources. Priority Requester: Desirable Requested by: Stanislav Visnovsky (visnov) Description: All packages are in a single file no matter if they are from different architectures, therefore ZYpp has to download everything Any kind of metadata should be separated by architecture. ZYpp does it for patterns in 10.3, but it is still missing for packages The metadata should be ideally separated by subdirectories and modules. See references on how debian does it References: https://bugzilla.novell.com/show_bug.cgi?id=208452 Relations: - No intel (32bit), 64 bit and ppc catalogs in one repository (inst- source) (novell/bugzilla/id: 309296) https://bugzilla.novell.com/show_bug.cgi?id=309296 Discussion: #1: Duncan Mac-Vicar (dmacvicar) (2007-11-09 16:52:55) This is not true, YaST filter patterns in 10.3. Will edit the feature to represent the real problems #2: Federico Lucifredi (flucifredi) (2008-06-13 20:22:10) Duncan, do we still need this / have an advantage from it ? if so, lets make it Mandatory. #3: Duncan Mac-Vicar (dmacvicar) (2008-06-26 13:17:09) This feature requires: - separate primary.xml files per architecture. 90% effort -> rudi , adrian - tell libzypp to ignore certain pattern or convention ( primary-x86_64. xml ??? ) when downloading -> one liner. It is not much benefit anymore as we are much faster now, but I would recommend pset it to desirable and pass to Rudi and Adrian. #4: Stanislav Visnovsky (visnov) (2008-06-26 13:20:11) (reply to #3) Adrian, this is something for you. #5: Adrian Schröter (adriansuse) (2008-11-06 16:21:18) We have seperate ppc from i586/x86_64 to reduce size. We do not have seperation of meta data yet, but it would not help much anyway, as long as we have no filter on rebuild. All files would change anyway, so the size would be the same. It would actually slow down the process due to multiple downloads. -- openSUSE Feature: https://features.opensuse.org/302354

1 0

[openFATE 305500] User has no way to switch compiz on / off
by fate_noreply＠suse.de 05 Oct '09

05 Oct '09

Feature changed by: Cameron Blackwood (drkorg) Feature #305500, revision 15 Title: User has no way to switch compiz on / off openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Juergen Weigert (jnweiger) Description: I searched Yast, SAX, gnome-display-properties, and did a desktop search for 'compiz'. The switch is not well advertised, it is here: computer -> System: control-Center -> Look and Feel: Desktop Effects -> [ ] enable desktop effects. -> Close Command line: simple-ccsm, but not ccsm. I suggest to enhance yast to allow compiz switching, using the above information. And/or include package fusion-icon. + Discussion: + #4: Cameron Blackwood (drkorg) (2009-10-05 04:37:35) + +1. It would be great to be able to turn off all eye candy (for + remote/vnc hosts) or to crank it up to full (for desktops and laptops). + A simple 'no candy' or 'full candy' yast setting would be great! -- openSUSE Feature: https://features.opensuse.org/305500

1 0

[openFATE 307900] AOE (ata over ethernet) driver on install disk and mkinitrd == no harddisk
by fate_noreply＠suse.de 05 Oct '09

05 Oct '09

Feature added by: Cameron Blackwood (drkorg) Feature #307900, revision 1 Title: AOE (ata over ethernet) driver on install disk and mkinitrd == no harddisk openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Cameron Blackwood (drkorg) Description: Background: AOE is like iscsi, only simple (8 page spec, module already in kernel) and it works out of the box. Clients need the module (already in kernel) and a couple of support scripts (which just echo into control files). Setting up a vblade server is dead easy and provides you with an easy SAN virtual disk. (The server package is not in the standard pool, but can be found in the factory). What is required: Put the already existing aoe kernel module (about 40Kb) on the install dvd, create dead simple (see below) mkinitrd script, modify shutdown scripts to not hang when root is on a network drive. Why it would be useful: Media pc's, simple cluster nodes, 'thin' terminals. So the scenario would be, plug a small USB stick into a machine and boot the install DVD. Select the usb as /boot and an AOE disk as the rest of your filesystem. Install and you have a hard-disk less machine. Too easy! Proof of concept: See below. I managed to hack this process by installing to a hard disk, copying the filesystem to the AOE disk (making fstab changes) and then making an initrd that used aoe. Once I booted off that image I was hard disk free (except for my /boot which could easily live the previously mentioned USB stick). (I just tested that, you can make an ext2 filesystem on the usb stick and have /boot live there, install grub to it and you dont need the hard disk). Problems: On shutdown, the network service needs to be left on or we dont unmount the root filesystem cleanly (infact the shutdown hangs as you cant access / any more). I had a couple of similar problems playing with nfsroot too. Not sure about this process as I've only just started to look into network root filesystems. (Im sure anyone playing with nfsroot must have a solution to this). You obviously want to disable network stop on shutdown if your root device is a network device. I couldnt see any test in the init.d script for that. How to make a client boot off an AOE disk image (note how simple these scripts are, naturally they might need pollishing by someone who has a better understanding of mkinitrd, but i cant see that being more than 15 mins of someone's time). If these scripts were included in the mkinitrd rpm it would work out of the box. /lib/mkinitrd/scripts/setup-aoe.sh #!/bin/bash # #%stage: device # /lib/mkinitrd/scripts/setup-aoe.sh #!/bin/bash #%stage: block #%modules: aoe # modprobe aoe ls /dev/etherd echo "1" > /dev/etherd/discover ls /dev/etherd create image with: cp /boot/initrd /boot/aoe_initrd cp /boot/vmlinuz /boot/aoe_vmlinuz mkinitrd -i aoe_initrd -k aoe_vmlinuz -m aoe -f aoe -D eth0 and grub menu of: title aoe root (hd0,0) kernel /aoe_vmlinuz root=/dev/etherd/e9.1p3 splash=silent showopts vga=0x317 initrd /aoe_initrd -- openSUSE Feature: https://features.opensuse.org/307900

1 0

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

05 Oct '09

Feature changed by: Cameron Blackwood (drkorg) Feature #305296, revision 116 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Done 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 Test Case: * Log in to GNME/KDE * call beagle-status and check if beagle does not run. * Start searching in GNOME/KDE and check that the application ask you to start beagle. * After that run beagle-status again to check that beagle runs. 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. + #55: Cameron Blackwood (drkorg) (2009-10-05 03:50:38) (reply to #25) + Id prefer to not have it installed, but disabled by default comes a + close second. ;-) #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 #34: Marc collin (collinm) (2009-07-04 15:03:05) Disable it by default, i use kde... and there is alreay a solution for it.... we could also disable mono... #35: Michael Löffler (michl19) (2009-07-07 11:29:54) Vincent, can you do this? As it is our highest rated feature it would be very good to have implemented rather soon then later. Thanks. #36: Vincent Untz (vuntz) (2009-07-07 12:09:24) Well, it depends on what is the decision here: * if it's something that should be done during installation, I have no idea how to implement that. * If it's just disabling beagle by default, I'll need to investigate, but it hopefully only is changing something in a .desktop file. So what's the process on taking a decision here? That being said, just disabling beagle by default might expose a usability issue: if it's disabled, it will not index files. So when the user searches for something for the first time, it will not work and users won't understand it, and will just give up on it. (It might be solvable with a nice message the first time the user does a search, though) #37: Michael Löffler (michl19) (2009-07-07 14:43:12) (reply to #36) Vincent, please see #1. What you describe is exactly what Federico suggested as well. So I'd say disable beagle by default and offer option to run at first search. #38: Karl Eichwalder (keichwa) (2009-07-07 15:08:23) (reply to #37) IIRC, the kde help center works this way and it is rather annoying. Most of the time, the desktop computer idles... I think on the Mac the desktop search (spotlight) is enabled by default. #39: Stephan Kulow (coolo) (2009-07-07 15:16:24) (reply to #38) you're wrong. Most of the time, the desktop computer saves power. #40: Karl Eichwalder (keichwa) (2009-07-07 15:36:52) (reply to #39) Yes, you are right. Once the work is done. On my desktop at work, beagled and beagled-helper do not cause any notable load. It's different on my test machine, though. #41: Dean Hilkewich (deanjo13) (2009-07-07 16:36:55) (reply to #38) When it comes to indexing services spotlight is far ahead of beagle in usability and performance. It is also easily disabled with a system setting if desired. Even on old G4's spotlight doesn't kill performance like beagle does. #42: Segundo Luis Martín Díaz Sotomayor (zchronos) (2009-07-07 17:47: 18) Beagle should be disabled by default. #49: Vincent Untz (vuntz) (2009-07-18 18:42:21) Fixed in GNOME:Factory, and submitted to openSUSE:Factory (#14802). #51: Hecke Degering (hecke_goe) (2009-08-10 09:02:11) just heard about this request... i would like to strongly support it. Beagle eats way too much ressources away for something to be convenient. btw: in our institutes desktop configuration (OpenSuse, ~60machines) we got rid of beagle totally. Unfortunately some packages depend on beagle- lib, so there is some leftover in the package selection, but this should not harm, hopefully;-) #52: Richard Lennox (rlx01) (2009-08-13 15:57:12) I agree. It just gets in the way. Disable it by default. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305324] Netcontrol does not set up WLAN when kill switch activated
by fate_noreply＠suse.de 02 Oct '09

02 Oct '09

Feature changed by: Marius Tomaschewski (mtomaschewski) Feature #305324, revision 12 Title: Netcontrol does not set up WLAN when kill switch activated openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Important Requested by: Marius Tomaschewski (mtomaschewski) Description: Provide udev rule to activate / deactivate WLAN interface based on killswitch event --- On my Lenovo ThinkPad T60p, the WLAN hardware kill switch doesn't work as expected. I am _NOT_ using NetworkManager, but the traditional ifup method. The problem seems to be, that the wlan interface is not properly brought up/down when I use the kill switch. --- This wont be fixed for 11.0, because there are different types of killswitch events for different drivers. And it works with NetworkManager. But for 11.1 we should be able to handle it more easily. There will be unified killswitch events. What we need is a additional udev rule that calls ifup for that event. Relations: - Netcontrol does not set up WLAN when kill switch activated (novell/bugzilla/id: 383309) https://bugzilla.novell.com/show_bug.cgi?id=383309 Discussion: #1: Jan Engelhardt (jengelh) (2009-06-18 23:52:42) Is not the kill switch handled directly in the kernel? #2: Vladimir Botka (vbotka) (2009-09-08 21:38:00) In the case of the Thinkpad T60 the killswitch is handled by the acpid. This even is sent via HAL to the d-bus. The corresponding application should act on this event. AFACT neither Network Manger nor ifup/ifdown act to this event. The signal the HAL sends to the d-bus is from *acpi_rfkill_tpacpi_bluetooth_* . I can see that the bluetooth device is switching on/off on this signal. + #3: Marius Tomaschewski (mtomaschewski) (2009-10-02 08:55:32) (reply to + #2) + Netcontrol alias ifup does not listen to any d-bus events. A udev event is + required. -- openSUSE Feature: https://features.opensuse.org/305324

1 0

[openFATE 305301] Central Regulatory Domain Agent (for 802.11)
by fate_noreply＠suse.de 02 Oct '09

02 Oct '09

Feature changed by: Marius Tomaschewski (mtomaschewski) Feature #305301, revision 32 Title: Central Regulatory Domain Agent (for 802.11) openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Vladimir Botka (vbotka) Description: The regulatroy domain handling for wireless cards was done by each driver seperately before mac80211/cfg80211. cfg80211 is used to unify the handling of regulatory domains for wireless devices. However cfg80211 depends on the user space configuring the regulatory domain. A user space daemon is currently developed (see [1]). It basically provides the allowed channels for all known regulatory domains. Additionally it would be nice to allow the configuration of the regulatory domain from the Yast network module. [1] http://wireless.kernel.org/en/developers/Regulatory/CRDA Partly based on bnc#392853 Relations: - wpa_supplicant in factory seems to ignore an country=DE setting in its config (novell/bugzilla/id: 537708) https://bugzilla.novell.com/show_bug.cgi?id=537708 Discussion: #1: Helmut Schaa (hschaa) (2009-02-03 12:04:57) I've already packaged crda and wireless-regdb in my buildservice project home:hschaa:CRDA. #2: Helmut Schaa (hschaa) (2009-02-09 11:37:20) What we additionally need for this feature is some integration with Yast or NetworkManager such that the user is able to set the regulatory domain (maybe based on the selected time zone). A command line tool for setting the domain is already available (iw) but needs to be updated. #3: Helmut Schaa (hschaa) (2009-02-09 16:09:28) (reply to #2) Just submitted an update for Factory. #4: Helmut Schaa (hschaa) (2009-02-10 10:59:40) (reply to #2) wpa_supplicant 0.6.7 already has support for setting the regulatory domain. We'll get that with the next version update. #5: Helmut Schaa (hschaa) (2009-02-10 13:40:25) (reply to #2) iw, crda and wireless-regdb are part of factory now #6: Kshitij Kulshreshtha (polyconvex) (2009-03-25 11:53:33) Sometimes on a short visit abroad a user might not bother to update their timezone information on their laptop but still want to use a wireless network. In this case setting the regulatory domain based on timezone is not the right thing to do. Why not let the networkmanager applet ask the user himself to provide the country as a part of the dialog to setup the network? (A map similar to the yast timezone selector built into KNetworkManager?) #7: Marius Tomaschewski (mtomaschewski) (2009-06-08 11:27:49) We've already another enhancement bugs for sysconfig/wireless... so let's just add it for 11.2. Helmut, let's speak in the next days about the requirements on the sysconfig side (I guess it is just one optional variable) and add this together with the another enhancements. Michal (yast2 network) requires the sysconfig support to implement it on the yast2 side. #11: Marius Tomaschewski (mtomaschewski) (2009-09-08 15:56:43) (reply to #9) Let's define the sysconfig ifcfg -file variable as: WIRELESS_REGULATORY_DOMAIN='00' The '00' value is the ISO / IEC 3166 alpha2 country code as used in the regdb / wpa_supplicant / iw tool. The _sysconfig_ default is '' , that is empty string. #12: Marius Tomaschewski (mtomaschewski) (2009-09-08 16:39:46) (reply to #11) Hmm... it looks like the reg domain is a global and not a per-interface setting, in iw: reg set <ISO/IEC 3166-1 alpha2> reg get this means it has to go to network/config and not into ifcfg file. Is this correct? #15: Jiri Benc (jbenc) (2009-09-09 13:23:09) (reply to #12) Yes, this is a system-wide setting. On purpose, you don't usually have you computer in two different regulatory zones ;-) I don't see what's the problem with using the timezone setting, though. Yes, it would require a translation table (to map e.g. Europe/Prague to CZ), but other than that, it should provide all the information we need: in what country we are located. #16: Marius Tomaschewski (mtomaschewski) (2009-09-09 13:53:06) (reply to #15) OK, thanks for verifying this! I don't have any problem when yast2 is setting the WIRELESS_REGULATORY_DOMAIN='CZ' value based on the TIMEZONE='Europe/Prague' setting by default / as preselection. But I need the correct, valid and final value for the utilities and don't want to provide any translation table and waste e.g. boot time in sysconfig. It also makes sense to check that the alpha-2 code is in the wireless-regdb and perhaps propose an another value if possible or reject & reset it -- in sysconfig it is too late to do this or ask the user what to do. The package implementing this is in Base:System/sysconfig project and goes to factory today. When iw reg set is used, the value is applied correctly to the crda/kernel. When it is set via wpa_supplicant config, there is no attempt to set it visible in udev -- seems to be a wpa_supplicant bug -> bugzilla. #17: Jiri Benc (jbenc) (2009-09-09 14:01:13) (reply to #16) Yes, all of that makes sense to me. #18: Vladimir Botka (vbotka) (2009-09-09 20:34:24) (reply to #16) Part of the project http://linuxwireless.org/en/developers/Documentation/nl80211 is also an wpa_supplicant with -Dnl80211 which will solves this problem. The yast module can set both the WIRELESS_REGULATORY_DOMAIN in sysconfig and country= in wpa_supplicant.conf. #20: Marius Tomaschewski (mtomaschewski) (2009-09-09 22:40:21) (reply to #18) Stop :-) sysconfg / ifup is not using /etc/.../wpa_supplicant.conf -- it generates one per interface from network/config and network/ifcfg* settings. So just set the WIRELESS_REGULATORY_DOMAIN, ifup-wireless will add the (expanded) "country=$WIRELESS_REGULATORY_DOMAIN" statement to the generated wpa_supplicant config. #19: Vladimir Botka (vbotka) (2009-09-09 21:34:26) (reply to #16) The new nl80211 extension is already available in Factory. # wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -i wlan0 -dd - Dnl80211 Initializing interface 'wlan0' conf '/etc/wpa_supplicant/wpa_supplicant.conf' driver 'nl80211' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant/wpa_supplicant.conf' -> '/etc/wpa_supplicant/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant/wpa_supplicant.conf' country='CZ' #21: Marius Tomaschewski (mtomaschewski) (2009-09-09 22:42:34) (reply to #19) Yes I know already about the new driver. Question is if we can switch to use this driver already. Let's continue with the driver details in bugzilla. + #22: Marius Tomaschewski (mtomaschewski) (2009-10-02 08:52:57) + FYI: The sysconfig-0.72.4 version in openSUSE:Factory / 11.2 implements + this feature. + It provides the WIRELESS_REGULATORY_DOMAIN variable and adds it to the + per-interface wpa_supplicant.conf as well as sets it via iw command in + case of old (iwconfig) setup. It does not change to the new nl80211 + driver (or another one supporting it) by default, the user has to set + WIRELESS_WPA_DRIVER="nl80211" per interface or wpa_supplicant will + ignore it. -- openSUSE Feature: https://features.opensuse.org/305301

1 0

[openFATE 303532] Reduce size of updates for openSUSE Factory
by fate_noreply＠suse.de 01 Oct '09

01 Oct '09

Feature changed by: Ralph Ulrich (ulenrich) Feature #303532, revision 32 Title: Reduce size of updates for openSUSE Factory Buildservice: Evaluation Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-06-06 09:06:29 reject reason: not really attached to a specific openSUSE version Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter (adriansuse) reject date: 2008-11-06 16:10:03 reject reason: This is a build service feature, but no distribution feature. Priority Requester: Important Projectmanager: Important Requested by: Michael Löffler (michl19) Description: Each update currently is around 2GB which is already much for broadband bandwith. For user with less bandwith it's by and large impossible to use Factory. Goal is to reduce size of updates and stay with frequent updates to offer latest software to the user. As we want more people using Factory it's usage needs to be conveniant. Discussion: #1: Stephan Kulow (coolo) (2008-03-27 16:48:43) According to discussions with Rudi and mls, the delta setup on dist need to be changed to also contain the rpm header and the deltas need to be indexed in a way that zypp will see them. So we can still use drpmsync for internal distribution and put the deltas only in instsource for mirrors. #2: Duncan Mac-Vicar (dmacvicar) (2008-04-22 13:28:56) This will happen automatically once the remaining parts of libzypp deltarpm handling are finished. We only need to agree on the format. I will propose something today. #3: Duncan Mac-Vicar (dmacvicar) (2008-05-26 17:09:31) ZYpp side is done. The only thing that needs to be done is to generate the deltarpm metadata in factory. I will post link to documentation and examples shortly. #7: Andreas Jaeger (a_jaeger) (2009-07-14 21:36:57) (reply to #3) What is the status of the Build Service side for this? #8: Adrian Schröter (adriansuse) (2009-09-15 16:42:11) (reply to #7) Partly implemented, the build-compare support exists, delta generation support is currently out of scope (if done on build host, it would need adaptions in backend parts. If done on extra(mirror) host, it would need to resign content, which breaks security concepts). #4: Gerald Pfeifer (geraldpfeifer) (2009-01-03 14:54:00) Opening this up for openSUSE.org. #5: Stephan Kulow (coolo) (2009-01-16 08:24:42) ok, we discussed this a bit further. We plan to throw away builds that are equal to the previous build and publish deltas generated by the build clients if they are not equal. If a build is equal is to be defined, for now it's a shell script that checks various properties - and works acceptable for now. I rebuild a good portion of 11.1 without further changes and get 7345 binary rpms (including all subpackages). 5666 are considered equal by my current script (based on work by Michael Matz). And many of other packages are possible to fix, so they are equal too. So this gives for uneffected rebuilds a huge reduction of updates. The kernels and kmps are currently seen as !equal after an uneffected rebuild as they put the %release (rebuild counter) in many places. Not sure how much the script should work around such cases. But even for those the download size would reduce: kernel-default.i586 (with base and extra): 25.7MB to download deltas of it: 6.7MB (I think the kernel puts a lot of "rebuild on" info in the code) #6: Piotrek Juzwiak (benderbendingrodriguez) (2009-06-17 17:29:42) As an addition to that it would be great if the older package would stay until the second rebuild so that if something breaks we could go back to the previous version and report that something's wrong with the new one. #9: Lars Vogdt (lrupp) (2009-10-01 12:33:06) (reply to #6) Having backups is always a good idea. But as we've just limited space (internally and on our mirrors) I don't think that we can implement this. #10: Stephan Kulow (coolo) (2009-10-01 13:03:18) (reply to #9) download.o.o will keep the old versions alive and the mirrors only get the latest. + #11: Ralph Ulrich (ulenrich) (2009-10-01 14:56:11) + Why not a more differentiated factory scheme like Debian: + - unstable + - testing (less frequently changes) + Something similar is implemented now using factory snapshots ? -- openSUSE Feature: https://features.opensuse.org/303532

1 0

[openFATE 303532] Reduce size of updates for openSUSE Factory
by fate_noreply＠suse.de 01 Oct '09

01 Oct '09

Feature changed by: Stephan Kulow (coolo) Feature #303532, revision 31 Title: Reduce size of updates for openSUSE Factory Buildservice: Evaluation Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-06-06 09:06:29 reject reason: not really attached to a specific openSUSE version Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter (adriansuse) reject date: 2008-11-06 16:10:03 reject reason: This is a build service feature, but no distribution feature. Priority Requester: Important Projectmanager: Important Requested by: Michael Löffler (michl19) Description: Each update currently is around 2GB which is already much for broadband bandwith. For user with less bandwith it's by and large impossible to use Factory. Goal is to reduce size of updates and stay with frequent updates to offer latest software to the user. As we want more people using Factory it's usage needs to be conveniant. Discussion: #1: Stephan Kulow (coolo) (2008-03-27 16:48:43) According to discussions with Rudi and mls, the delta setup on dist need to be changed to also contain the rpm header and the deltas need to be indexed in a way that zypp will see them. So we can still use drpmsync for internal distribution and put the deltas only in instsource for mirrors. #2: Duncan Mac-Vicar (dmacvicar) (2008-04-22 13:28:56) This will happen automatically once the remaining parts of libzypp deltarpm handling are finished. We only need to agree on the format. I will propose something today. #3: Duncan Mac-Vicar (dmacvicar) (2008-05-26 17:09:31) ZYpp side is done. The only thing that needs to be done is to generate the deltarpm metadata in factory. I will post link to documentation and examples shortly. #7: Andreas Jaeger (a_jaeger) (2009-07-14 21:36:57) (reply to #3) What is the status of the Build Service side for this? #8: Adrian Schröter (adriansuse) (2009-09-15 16:42:11) (reply to #7) Partly implemented, the build-compare support exists, delta generation support is currently out of scope (if done on build host, it would need adaptions in backend parts. If done on extra(mirror) host, it would need to resign content, which breaks security concepts). #4: Gerald Pfeifer (geraldpfeifer) (2009-01-03 14:54:00) Opening this up for openSUSE.org. #5: Stephan Kulow (coolo) (2009-01-16 08:24:42) ok, we discussed this a bit further. We plan to throw away builds that are equal to the previous build and publish deltas generated by the build clients if they are not equal. If a build is equal is to be defined, for now it's a shell script that checks various properties - and works acceptable for now. I rebuild a good portion of 11.1 without further changes and get 7345 binary rpms (including all subpackages). 5666 are considered equal by my current script (based on work by Michael Matz). And many of other packages are possible to fix, so they are equal too. So this gives for uneffected rebuilds a huge reduction of updates. The kernels and kmps are currently seen as !equal after an uneffected rebuild as they put the %release (rebuild counter) in many places. Not sure how much the script should work around such cases. But even for those the download size would reduce: kernel-default.i586 (with base and extra): 25.7MB to download deltas of it: 6.7MB (I think the kernel puts a lot of "rebuild on" info in the code) #6: Piotrek Juzwiak (benderbendingrodriguez) (2009-06-17 17:29:42) As an addition to that it would be great if the older package would stay until the second rebuild so that if something breaks we could go back to the previous version and report that something's wrong with the new one. #9: Lars Vogdt (lrupp) (2009-10-01 12:33:06) (reply to #6) Having backups is always a good idea. But as we've just limited space (internally and on our mirrors) I don't think that we can implement this. + #10: Stephan Kulow (coolo) (2009-10-01 13:03:18) (reply to #9) + download.o.o will keep the old versions alive and the mirrors only get + the latest. -- openSUSE Feature: https://features.opensuse.org/303532

1 0

[openFATE 303532] Reduce size of updates for openSUSE Factory
by fate_noreply＠suse.de 01 Oct '09

01 Oct '09

Feature changed by: Lars Vogdt (lrupp) Feature #303532, revision 30 Title: Reduce size of updates for openSUSE Factory Buildservice: Evaluation Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-06-06 09:06:29 reject reason: not really attached to a specific openSUSE version Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter (adriansuse) reject date: 2008-11-06 16:10:03 reject reason: This is a build service feature, but no distribution feature. Priority Requester: Important Projectmanager: Important Requested by: Michael Löffler (michl19) Description: Each update currently is around 2GB which is already much for broadband bandwith. For user with less bandwith it's by and large impossible to use Factory. Goal is to reduce size of updates and stay with frequent updates to offer latest software to the user. As we want more people using Factory it's usage needs to be conveniant. Discussion: #1: Stephan Kulow (coolo) (2008-03-27 16:48:43) According to discussions with Rudi and mls, the delta setup on dist need to be changed to also contain the rpm header and the deltas need to be indexed in a way that zypp will see them. So we can still use drpmsync for internal distribution and put the deltas only in instsource for mirrors. #2: Duncan Mac-Vicar (dmacvicar) (2008-04-22 13:28:56) This will happen automatically once the remaining parts of libzypp deltarpm handling are finished. We only need to agree on the format. I will propose something today. #3: Duncan Mac-Vicar (dmacvicar) (2008-05-26 17:09:31) ZYpp side is done. The only thing that needs to be done is to generate the deltarpm metadata in factory. I will post link to documentation and examples shortly. #7: Andreas Jaeger (a_jaeger) (2009-07-14 21:36:57) (reply to #3) What is the status of the Build Service side for this? #8: Adrian Schröter (adriansuse) (2009-09-15 16:42:11) (reply to #7) Partly implemented, the build-compare support exists, delta generation support is currently out of scope (if done on build host, it would need adaptions in backend parts. If done on extra(mirror) host, it would need to resign content, which breaks security concepts). #4: Gerald Pfeifer (geraldpfeifer) (2009-01-03 14:54:00) Opening this up for openSUSE.org. #5: Stephan Kulow (coolo) (2009-01-16 08:24:42) ok, we discussed this a bit further. We plan to throw away builds that are equal to the previous build and publish deltas generated by the build clients if they are not equal. If a build is equal is to be defined, for now it's a shell script that checks various properties - and works acceptable for now. I rebuild a good portion of 11.1 without further changes and get 7345 binary rpms (including all subpackages). 5666 are considered equal by my current script (based on work by Michael Matz). And many of other packages are possible to fix, so they are equal too. So this gives for uneffected rebuilds a huge reduction of updates. The kernels and kmps are currently seen as !equal after an uneffected rebuild as they put the %release (rebuild counter) in many places. Not sure how much the script should work around such cases. But even for those the download size would reduce: kernel-default.i586 (with base and extra): 25.7MB to download deltas of it: 6.7MB (I think the kernel puts a lot of "rebuild on" info in the code) #6: Piotrek Juzwiak (benderbendingrodriguez) (2009-06-17 17:29:42) As an addition to that it would be great if the older package would stay until the second rebuild so that if something breaks we could go back to the previous version and report that something's wrong with the new one. + #9: Lars Vogdt (lrupp) (2009-10-01 12:33:06) (reply to #6) + Having backups is always a good idea. But as we've just limited space + (internally and on our mirrors) I don't think that we can implement + this. -- openSUSE Feature: https://features.opensuse.org/303532

1 0