April 2008 - openSUSE Features - openSUSE Mailing Lists

[Fate 303708] Mascot for YaST
by fate_noreply＠suse.de 24 Apr '08

24 Apr '08

Feature changed by: michl Feature #303708, revision 7 Title: Mascot for YaST openSUSE-11.1: Evaluation Priority Requester: Mandatory Requested by: aj(a)novell.com Partner organization: openSUSE.org Description: Every successfull product has it's own logo and mascot. We should create and market one for YaST as well, display it prominently on all YaST project pages and also in YaST, e.g. in any About screens or as easter egg. Discussion: #2: michl(a)novell.com (2008-04-24 12:46:55) I'm fine with that. I think this should come out of the inner YaST circle with some help from design people like Jakub. + #3: michl(a)novell.com (2008-04-24 19:54:31) (reply to #2) + And we should inlcude the community on that. Zonker might call for + ideas/participation for logo creation on his blog and news.openSUSE. + org -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303708

1 0

[Fate 303708] Mascot for YaST
by fate_noreply＠suse.de 24 Apr '08

24 Apr '08

Feature changed by: michl Feature #303708, revision 4 Title: Mascot for YaST openSUSE-11.1: Evaluation Priority Requester: Mandatory Requested by: aj(a)novell.com Partner organization: openSUSE.org Description: Every successfull product has it's own logo and mascot. We should create and market one for YaST as well, display it prominently on all YaST project pages and also in YaST, e.g. in any About screens or as easter egg. + Discussion: + #2: michl(a)novell.com (2008-04-24 12:46:55) + I'm fine with that. I think this should come out of the inner YaST + circle with some help from design people like Jakub. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303708

1 0

[Fate 303708] Mascot for YaST
by fate_noreply＠suse.de 24 Apr '08

24 Apr '08

Feature changed by: aj Feature #303708, revision 3 Title: Mascot for YaST - openSUSE-11.1: New + openSUSE-11.1: Evaluation Priority Requester: Mandatory Requested by: aj(a)novell.com Partner organization: openSUSE.org Description: Every successfull product has it's own logo and mascot. We should create and market one for YaST as well, display it prominently on all YaST project pages and also in YaST, e.g. in any About screens or as easter egg. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303708

1 0

[Fate 303708] Mascot for YaST
by fate_noreply＠suse.de 24 Apr '08

24 Apr '08

Feature added by: aj Feature #303708, revision 1 Title: Mascot for YaST openSUSE-11.1: New Priority Requester: Mandatory Requested by: aj(a)novell.com Partner organization: openSUSE.org Description: Every successfull product has it's own logo and mascot. We should create and market one for YaST as well, display it prominently on all YaST project pages and also in YaST, e.g. in any About screens or as easter egg. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303708

1 0

[Fate 302354] Split metadata by architecture / modules
by fate_noreply＠suse.de 23 Apr '08

23 Apr '08

Feature changed by: visnov Feature #302354, revision 7 Title: Split metadata by architecture / modules openSUSE-11.0: Rejected by visnov(a)novell.com 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: New Priority Requester: Important Requested by: visnov(a)novell.com + Partner organization: openSUSE.org 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 Discussion: #1: dmacvicar(a)novell.com (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 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=302354

1 0

[Fate 303678] New yast module - LIRC configuration
by fate_noreply＠suse.de 22 Apr '08

22 Apr '08

Feature added by: lslezak Feature #303678, revision 1 Title: New yast module - LIRC configuration openSUSE-11.1: New Priority Requester: Desirable Requested by: lslezak(a)novell.com Partner organization: openSUSE.org Description: Create a new Yast module for configuring IR receivers and remote controls. * irrecord support * ir-kbd-i2c, ir-kbd-gpio support as in tv module already * reading users' config to find out what buttons were defined (only if /home partition left from last installation) * support for lirc's options in /etc/sysconfig See bug https://bugzilla.novell.com/show_bug.cgi?id=381641 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303678

1 0

[Fate 302919] Improved argument handling for zypper
by fate_noreply＠suse.de 21 Apr '08

21 Apr '08

Feature changed by: jkupec Feature #302919, revision 8 Title: Improved argument handling for zypper - openSUSE-11.0: Candidate + openSUSE-11.0: Done Priority Requester: Mandatory Projectmanager: Important - SLED-11: New + SLED-11: Done Priority Requester: Mandatory - SLES-11: New + SLES-11: Done Priority Requester: Mandatory Requested by: kkaempf(a)novell.com Partner organization: openSUSE.org Description: Please improve argument handling on the zypper command line. zypper install foo should look for a package named foo and, if no such package exist, do an automatic fallback to a capability. The --name qualifier can be used to prevent this fallback (forces a package name. The --capability qualifier can be used to force a capability. - Specifying versions and operators should also be more flexible (Following the motto be generous in what you accept, and strict in what you send ) zypper in foo-1.2-3 should try to install package foo, version 1.2, release 3. zypper in foo-1.2 should try to install package foo, version 1.2, any release. zypper in foo should try to install package foo, any version, any release. When specifying operators, spaces should be accepted, i.e. zypper in foo = 1.2-3 - Forcing a specific repository could be done by prefixing the package name with the repository alias followed by a colon, i.e. zypper in opensuse:foo - To be discussed on opensuse-softwaremgmt and cross-checked with other tools like smart and yum. Discussion: #1: visnov(a)novell.com (2007-11-23 11:24:48) zypper improvements. #2: jkupec(a)novell.com (2008-04-14 15:02:32) All of the orginal suggestions are implemented, except for per-package forcing of repositories. Can i mark as done? I also thought of install foo@arch postfix to force specific architecture. There is no libzypp API for per-package forcing of repository or architecture but it's doable in zypper the old (forced) way. Would take only few more hours. #3: jkupec(a)novell.com (2008-04-14 14:58:01) BTW, we've got wildcard support, install/remove in one go using +/- ~/! prefix (+maybe more i cannot recall now) as bonus :O) Details will be added to the man page and wiki later. + #4: jkupec(a)novell.com (2008-04-21 13:29:15) + All done in zypper 0.11.1 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=302919

1 0

[Fate 302919] Improved argument handling for zypper
by fate_noreply＠suse.de 14 Apr '08

14 Apr '08

Feature changed by: jkupec Feature #302919, revision 6 Title: Improved argument handling for zypper openSUSE-11.0: Candidate Priority Requester: Mandatory Projectmanager: Important SLED-11: New Priority Requester: Mandatory SLES-11: New Priority Requester: Mandatory Requested by: kkaempf(a)novell.com Partner organization: openSUSE.org Description: Please improve argument handling on the zypper command line. zypper install foo should look for a package named foo and, if no such package exist, do an automatic fallback to a capability. The --name qualifier can be used to prevent this fallback (forces a package name. The --capability qualifier can be used to force a capability. - Specifying versions and operators should also be more flexible (Following the motto be generous in what you accept, and strict in what you send ) zypper in foo-1.2-3 should try to install package foo, version 1.2, release 3. zypper in foo-1.2 should try to install package foo, version 1.2, any release. zypper in foo should try to install package foo, any version, any release. When specifying operators, spaces should be accepted, i.e. zypper in foo = 1.2-3 - Forcing a specific repository could be done by prefixing the package name with the repository alias followed by a colon, i.e. zypper in opensuse:foo - To be discussed on opensuse-softwaremgmt and cross-checked with other tools like smart and yum. Discussion: #1: visnov(a)novell.com (2007-11-23 11:24:48) zypper improvements. + #2: jkupec(a)novell.com (2008-04-14 15:02:32) + All of the orginal suggestions are implemented, except for per-package + forcing of repositories. Can i mark as done? + I also thought of install foo@arch postfix to force specific + architecture. There is no libzypp API for per-package forcing of + repository or architecture but it's doable in zypper the old (forced) + way. Would take only few more hours. + #3: jkupec(a)novell.com (2008-04-14 14:58:01) + BTW, we've got wildcard support, install/remove in one go using +/- ~/! + prefix (+maybe more i cannot recall now) as bonus :O) Details will be + added to the man page and wiki later. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=302919

1 0