July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306771] Visual Basic Programming in Linux
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature added by: John Shand (jshand2008) Feature #306771, revision 1 Title: Visual Basic Programming in Linux openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: John Shand (jshand2008) Description: I am also a well seasoned Visual Basic Programmer in need of an openSUSE clone so i can keep writing database software. i would appreciate any feedback on this -- openSUSE Feature: https://features.opensuse.org/306771

1 4

[openFATE 306769] Permanent File Shreeder on a Ext3/Ext4 file system
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature added by: John Shand (jshand2008) Feature #306769, revision 1 Title: Permanent File Shreeder on a Ext3/Ext4 file system openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: John Shand (jshand2008) Description: If you work on a business machine like i do and you later decide to sell it, you wouldn't want all your business secrets going out the door with computer. So a cd boot up tool would be handy if you wish to totally clean your hard drive from that information before selling it. -- openSUSE Feature: https://features.opensuse.org/306769

1 2

[openFATE 306407] Do not make lang packages mandatory
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Stephan Kulow (coolo) Feature #306407, revision 9 Title: Do not make lang packages mandatory openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Mandatory Requested by: Vincent Untz (vuntz) Description: Right now, packages which have a split lang package have "Requires: % {name]-lang". I think that in most cases, this requires is wrong and it should really be a Recommends. FWIW, one thing that is blocking to implement this for GNOME is that the english help files automatically end up in the lang package, while they shouldn't: https://bugzilla.novell.com/show_bug.cgi?id=449847 Discussion: #1: Stephan Binner (beineri) (2009-05-07 08:59:25) The -lang and bundle packages contain also en/C data files and/or manuals. Or you sure that every application checks correctly for their absence? #2: Vincent Untz (vuntz) (2009-05-07 13:09:28) (reply to #1) Stephan: that's more or less the bug I linked to :-) We certainly need to be careful and check for this kind of stuff. #3: Andreas Jaeger (a_jaeger) (2009-07-09 14:32:59) Coolo, could you comment on this and evaluate it, please? #4: Stephan Kulow (coolo) (2009-07-09 14:35:49) (reply to #3) meanwhile I'm convinced myself that using Requires is wrong - as we're cheating anyway in only giving it e.g. german or spanish language. #5: Stephan Kulow (coolo) (2009-07-09 14:36:29) (reply to #4) the question though is: who will do this. We should do it consistently I guess. #6: Ludwig Nussel (lnussel) (2009-07-09 15:04:33) (reply to #5) Consistency can be enforced later. Officially allowing/encouraging Recommends would be quite helpful already so packages can be changed if they need to be touched anyways. + #7: Stephan Kulow (coolo) (2009-07-14 15:52:46) (reply to #6) + I'm actually not aware of any policy that forbids recommends. It's just + current practice. -- openSUSE Feature: https://features.opensuse.org/306407

1 0

[openFATE 305641] Bring Puppet to fully supportable status
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305641, revision 20 Title: Bring Puppet to fully supportable status - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Dedicate a developer for the duration of the 11.2 cycle to shaking out Puppet on openSUSE, contribute patches upstream correcting integration with our base system, and analyzing what future integration areas (particularly with YaST, but not limited) appear promising. The objective is to walk through the Puppet documentation (http://reductivelabs.com/trac/puppet/wiki/DocumentationStart), Turnbull's book (ISBN 159059978), and test out that things work as they should, patching and sending upstream when they do not. Finally, contribute a small "Puppet on SUSE" document to the community detailing any platform- specific factors (you will see there are a number for other distors already). Additional notes: The plan is to _INSTALL_ the Puppet infrastructure by default. No default-running is planned - I thought it was important to clarify this. Addtionally, Facter needs to be packaged and supportable alongside Puppet. Cft should be packaged, but not default installed, and not the target of this focused infrastructure work in this cycle (i.e. Best effort). Relations: - Feature for 11 GA tech Preview (feature/id: 303687) Business case (Partner benefit): openSUSE.org: The ultimate intent is to integrate a policy management framework into the platform and have it available as default infrastructure. This has a number of consequencies: for one, the ability of third parties, both internal and external, to leverage the policy language for platform management. Secondly, I want to support the Puppet objective of being a pervasive policy language for *NIX, which may or may not be achievable. This combines with the set of enabling management technologies we want to have on the platform as blocks to build on: integrated libraries (libzypp, libstorage, ..), management instrumentation (SFCB, management profiles exposing the libraries wherever possible), Stateless YaST interface (to enable access to configuration facilities), and support instrumentation (the Novell Support Link, formerly known as Aurora and Onstar). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-08 16:25:48) . #2: Federico Lucifredi (flucifredi) (2009-01-26 18:49:40) As per for phone conversation, this requirement is not only about technology ("Policy framework"), but also about the political decision of what solution to adopt - in which context the technology is not an Engineering decision, but a Business one. I am chosing Puppet on the theory that we will do our bit to help the rise of a cross-*NIX management tool by making it available and supported. If the interest in Puppet contines at this pace, and other things go the right way, we will consider further investment. For now, we just make Puppet (and Facter with it) L3 supported. If the market keeps moving in this direction, then good, we will integrate beyond the "managing by configuration file" scheme, and look at what YaST integration we can do. If it does not, we just keep the L3 package and move3 on. Think of it as Perl - it is on Every *NIX, and if you use it is good if not, it does not hurt. #3: Pavol Rusnak (prusnak) (2009-02-10 15:45:06) I think anicka did some experiments with puppet. #4: Duncan Mac-Vicar (dmacvicar) (2009-04-15 09:35:35) Progress note: integration of the community authored zypper plugin for puppet is integrated (and working) and will be submitted to stable. #5: Duncan Mac-Vicar (dmacvicar) (2009-06-02 11:24:28) We added a patch to support zypper for puppet package ensure policies, which is submitted. Marking as in implementation. Could in theory be marked as done if we had any criteria. -- openSUSE Feature: https://features.opensuse.org/305641

1 0

[openFATE 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Jan Holesovsky (kendysan) Feature #304879, revision 86 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Binner (beineri) Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Use Case: I will find this is really usefull. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. #9: Ruurd Pels (rfpels) (2009-03-06 22:40:10) Seems to me now that we have 4.2 in FACTORY for 11.1 we can create and release an integration package there so we will be ready by the time SLES11 goes gold. #14: Michael Löffler (michl19) (2009-07-14 12:13:49) (reply to #9) Jan, can you comment on #9. As this feature is one of the highest rated ones we should start implementation better sooner than later. + #15: Jan Holesovsky (kendysan) (2009-07-14 15:15:21) (reply to #14) + We now have a proof of concept KDE4 integration in ooo-build, it will + be a part of OOo 3.1.1. So far the theming and the file dialog were + ported; also the Oxygen icons for OOo were provided - everything as a + community effort. For more information please see the comments 11, 12, + 13. #10: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:26:13) this would be nice for 11.2 #11: Karsten König (remur) (2009-06-15 15:23:55) Good news everybody! http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2… (Just for tracking, most openfate users propably have seen this by now on planetsuse) #12: jimbo bigcreed (dimble_thricefoon) (2009-06-16 18:41:27) (reply to #11) dot.kde http://www.kdedevelopers.org/node/3983 KDE4 integration done by the kubuntu boys #13: Stephan Binner (beineri) (2009-07-01 20:17:03) (reply to #12) An early OpenOffice_org-kde4 package exists in Factory so this should be change to Candidate. -- openSUSE Feature: https://features.opensuse.org/304879

1 0

[openFATE 306476] Install boot entry configurable in kernel git file
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #306476, revision 7 Title: Install boot entry configurable in kernel git file - openSUSE-11.2: Unconfirmed + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Thomas Renninger (trenn) Description: Provide a file in the kernel git which describes an installation boot entry including: - help/description - specific boot parameters - active on which arch The installation image (e.g. DVD) will then provide these specific boot entries to make it easy for: - kernel developers to add critical boot parameters required for specific HW for booting - users by providing a meaningful help at boot loader start up Currently most important settings that are coming to my mind are: - apic=bigsmp (for i386 machines with a lot cores might require that) - disable Kernel Mode Settings -> disable kernel graphics parts which won't work on all HW if set by default soon The idea originally comes from Bernhard Walle. Steffen and myself discussed that already and agreed that it makes sense to do that. On longterm it would be great to get rid of the "Failsafe" Yast boot loader functionality. This would not be necessary anymore then. This currently totally useless and outdated anyway. With the new approach, soon as one successfully booted an entry from the installation image, these boot options will be the default forever (or manually adjusted). Discussion: #1: Stefan Dirsch (sndirsch) (2009-06-22 10:09:05) I think the X' team' would like to get involved here WRT KMS. Also I believe we still want to have a possibility to detect that the user wants to start the Xserver from installation (usually fbdev driver) instead of the apparently broken native X driver. This was boot param 'x11failsafe' in the past. #2: Thomas Renninger (trenn) (2009-06-22 14:27:39) Yeah, in this case we probably need some advise from the X guys which boot params have to be passed, eventually other extra quirks are needed for KMS, no idea. But in general the responsibility and possibilty to generate/modify extra boot entries and with them passing extra kernel boot parameters and a description when to use them should rely in the kernel teams hands and thus the config file should lie in the kernel repo. Coolo, can you set this fate entry a project manager state, so that we can finally work on that at some time, thanks. #3: Stefan Dirsch (sndirsch) (2009-06-22 14:52:39) Probably the modeset option needs to be used for all relevant KMS capable DRM modules, like i915, radeon. Possibily also radeonhd (still to be implemented) and nouveau (in case it's installed, we don't ship it). So something like this: i915.modeset=0, radeon.modeset=0, radeonhd. modeset=0, nouveau.modeset=0. #5: Andreas Jaeger (a_jaeger) (2009-07-10 11:47:39) I'm a bit confused what you want to do here. What advantage will this bring us? + #6: Andreas Jaeger (a_jaeger) (2009-07-14 15:13:04) (reply to #5) + Just talked with Thomas: The idea is to safe the information about + kernel-parameters as part of the kernel package and let the + installation get this information from there - instead of hardcoding it + in the installation workflow. Also the kernel would provide different + options that the developers think make sense. -- openSUSE Feature: https://features.opensuse.org/306476

1 0

[openFATE 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Michael Löffler (michl19) Feature #304879, revision 85 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Binner (beineri) Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Use Case: I will find this is really usefull. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. #9: Ruurd Pels (rfpels) (2009-03-06 22:40:10) Seems to me now that we have 4.2 in FACTORY for 11.1 we can create and release an integration package there so we will be ready by the time SLES11 goes gold. + #14: Michael Löffler (michl19) (2009-07-14 12:13:49) (reply to #9) + Jan, can you comment on #9. As this feature is one of the highest rated + ones we should start implementation better sooner than later. #10: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:26:13) this would be nice for 11.2 #11: Karsten König (remur) (2009-06-15 15:23:55) Good news everybody! http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2… (Just for tracking, most openfate users propably have seen this by now on planetsuse) #12: jimbo bigcreed (dimble_thricefoon) (2009-06-16 18:41:27) (reply to #11) dot.kde http://www.kdedevelopers.org/node/3983 KDE4 integration done by the kubuntu boys #13: Stephan Binner (beineri) (2009-07-01 20:17:03) (reply to #12) An early OpenOffice_org-kde4 package exists in Factory so this should be change to Candidate. -- openSUSE Feature: https://features.opensuse.org/304879

1 0

[openFATE 306776] Yast Integration with PolicyKit
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature added by: Ney walens de Mesquita (nwm) Feature #306776, revision 1 Title: Yast Integration with PolicyKit openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Ney walens de Mesquita (nwm) Description: Would be very good, if Yast can integrate with PolicyKit permissions and provide ways of a regular non root user to configure modules and set values regarding Policykit permissions. -- openSUSE Feature: https://features.opensuse.org/306776

1 2

[openFATE 305553] zypper: dist upgrade could error out if more than one repository exists
by fate_noreply＠suse.de 13 Jul '09

13 Jul '09

Feature changed by: Michael Andres (mlandres) Feature #305553, revision 17 Title: zypper: dist upgrade could error out if more than one repository exists openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? + #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) + Yes. Since you can ask for a products CPEid, or for the CPEids related + to a repository (supported or updated products). But I don't know if + those CPEids are meanwhile included in the metadata (see bnc #459527). -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 306786] Manage KVM via VirtualBox Frontend
by fate_noreply＠suse.de 13 Jul '09

13 Jul '09

Feature added by: Matthias Eckermann (mge1512) Feature #306786, revision 1 Title: Manage KVM via VirtualBox Frontend Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Matthias Eckermann (mge1512) Description: While a VirtualBox backend for lib-virt has already been developed, see: http://libvirt.org/drvvbox.html (http://libvirt.org/drvvbox.html) , it is not yet implemented to manage other HVs (than the vbox internal HV) using the VirtualBox frontend. It is proposed to make the VirtualBox frontend use libvirt as a backend, to manage other HVs (KVM,Xen). -- openSUSE Feature: https://features.opensuse.org/306786

1 0