- openSUSE Features

[Fate 303527] Resolve dependencies after ignoring package download failure
by fate_noreply＠suse.de 19 Mar '08

19 Mar '08

Feature changed by: jsrain Feature #303527, revision 4 Title: Resolve dependencies after ignoring package download failure openSUSE-11.1: New Priority Requester: Desirable Requested by: jkupec(a)novell.com Partner organization: openSUSE.org Description: YaST and Zypper should run the solver before resuming installation if download of a package fails and the user chooses to ignore that package. Currently YaST continues withough solving which makes the ignore button useful only if the user knows how the missing package will affect the system. References: https://bugzilla.novell.com/show_bug.cgi?id=340345#c4 + http://lists.opensuse.org/zypp-devel/2008-03/msg00025.html -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303527

1 0

[Fate 303517] Configure a cronjob for refreshing repositories
by fate_noreply＠suse.de 18 Mar '08

18 Mar '08

Feature changed by: aj Feature #303517, revision 2 Title: Configure a cronjob for refreshing repositories - openSUSE-11.1: New + openSUSE-11.1: Evaluation Priority Requester: Desirable Requested by: lslezak(a)novell.com Partner organization: openSUSE.org Description: Autorefresh configured repositories at certain times, this could be on certain days, or time of day, etc. A mockup and more details are in https://bugzilla.novell.com/show_bug.cgi?id=346966 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303517

1 0

[Fate 303367] Better Beagle Acceptance
by fate_noreply＠suse.de 17 Mar '08

17 Mar '08

Feature changed by: gekker Feature #303367, revision 7 Title: Better Beagle Acceptance openSUSE-11.0: Evaluation Priority Requester: Mandatory + Projectmanager: Important Requested by: aj(a)novell.com Partner organization: openSUSE.org Description: There have been several discussions on the public openSUSE mailing lists, e.g. http://lists.opensuse.org/opensuse-factory/2008-01/msg00157.html where people complain about resource usage or garbage from beagle. I suggest that we analyze the current situation and check where are real problems and consider solutions. One option would be to make it easier for users to not enable beagle on their systems. Note: The feature request is about getting a better acceptance by our users of our indexing technology - and therefore let's figure out what are the problems they are hitting in real life. References: https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: aj(a)novell.com (2008-01-20 11:12:58) See also bug 282678. #2: aj(a)novell.com (2008-01-23 16:23:51) Note: powertop advises "Suggestion: Disable or remove 'beagle' from your system. Beagle is the program that indexes for easy desktop search, however it's not very efficient and costs a significant amount of battery life.". #3: jpr(a)novell.com (2008-01-23 10:38:58) (reply to #2) Yes, this is well known and was covered extensively last year and caused by polling for battery status in some cases. 0.3.2 uses hal to detect battery status: http://www.mail-archive.com/dashboard-hackers@gnome.org/msg03464.html #4: jpr(a)novell.com (2008-01-23 10:41:35) (reply to #3) Also part of it was a mono issue: http://www.nabble.com/Beagle-indexing-when-running-on-batteries-td13842939.… -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303367

1 0

[Fate 303527] Resolve dependencies after ignoring package download failure
by fate_noreply＠suse.de 11 Mar '08

11 Mar '08

Feature changed by: jkupec Feature #303527, revision 2 Title: Resolve dependencies after ignoring package download failure openSUSE-11.1: New Priority Requester: Desirable Requested by: jkupec(a)novell.com + Partner organization: openSUSE.org Description: YaST and Zypper should run the solver before resuming installation if download of a package fails and the user chooses to ignore that package. Currently YaST continues withough solving which makes the ignore button useful only if the user knows how the missing package will affect the system. References: https://bugzilla.novell.com/show_bug.cgi?id=340345#c4 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303527

1 0

[Fate 303517] Configure a cronjob for refreshing repositories
by fate_noreply＠suse.de 07 Mar '08

07 Mar '08

Feature added by: lslezak Feature #303517, revision 1 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: New Priority Requester: Desirable Requested by: lslezak(a)novell.com Partner organization: openSUSE.org Description: Autorefresh configured repositories at certain times, this could be on certain days, or time of day, etc. A mockup and more details are in https://bugzilla.novell.com/show_bug.cgi?id=346966 -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303517

1 0

[Fate 303493] zypper: add separate messages for Required and Recomended packages
by fate_noreply＠suse.de 28 Feb '08

28 Feb '08

Feature changed by: gp Feature #303493, revision 3 Title: zypper: add separate messages for Required and Recomended packages + openSUSE-11.0: Evaluation + Priority + Requester: Important SLES-11: Evaluation Priority Requester: Important Requested by: crrodriguez(a)novell.com Partner organization: openSUSE.org Description: currenly when you install a package with zypper, you just get the packages that are going to be installed, regardless if the are required or Reccommended,.. will be nice if the messages can be arranged to be more explict about what the package manager is doing. "The following NEW [required|reccomended] package is going to be installed: foo" also an informative message about Suggested packages should be shown "The following package(s) is(are) suggested but are not going to be installed foo bar " unless user pass --install-suggested or use a boolean configuration directive on zypp.conf or something, suggested packages should not be installed by default ..currently it seems to be completely ignored and does nothing. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303493

1 0

[Fate 303493] zypper: add separate messages for Required and Recomended packages
by fate_noreply＠suse.de 28 Feb '08

28 Feb '08

Feature changed by: aj Feature #303493, revision 2 - Title: zypper: add separate messages for Required and Reccommended + Title: zypper: add separate messages for Required and Recomended packages - SLES-11: New + SLES-11: Evaluation Priority Requester: Important Requested by: crrodriguez(a)novell.com Partner organization: openSUSE.org Description: currenly when you install a package with zypper, you just get the packages that are going to be installed, regardless if the are required or Reccommended,.. will be nice if the messages can be arranged to be more explict about what the package manager is doing. "The following NEW [required|reccomended] package is going to be installed: foo" also an informative message about Suggested packages should be shown - "The following package(s) is(are) suggsted but are not going to be + "The following package(s) is(are) suggested but are not going to be installed foo bar " unless user pass --install-suggested or use a boolean configuration directive on zypp.conf or something, suggested packages should not be installed by default ..currently it seems to be completely ignored and does nothing. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303493

1 0

[Fate 303493] zypper: add separate messages for Required and Reccommended packages
by fate_noreply＠suse.de 28 Feb '08

28 Feb '08

Feature added by: crrodriguez Feature #303493, revision 1 Title: zypper: add separate messages for Required and Reccommended packages SLES-11: New Priority Requester: Important Requested by: crrodriguez(a)novell.com Partner organization: openSUSE.org Description: currenly when you install a package with zypper, you just get the packages that are going to be installed, regardless if the are required or Reccommended,.. will be nice if the messages can be arranged to be more explict about what the package manager is doing. "The following NEW [required|reccomended] package is going to be installed: foo" also an informative message about Suggested packages should be shown "The following package(s) is(are) suggsted but are not going to be installed foo bar " unless user pass --install-suggested or use a boolean configuration directive on zypp.conf or something, suggested packages should not be installed by default ..currently it seems to be completely ignored and does nothing. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=303493

1 0

[Fate 302957] Combined "where am I" page
by fate_noreply＠suse.de 27 Feb '08

27 Feb '08

Feature changed by: locilka Feature #302957, revision 29 Title: Combined "where am I" page - openSUSE-11.0: Candidate + openSUSE-11.0: Done Priority Requester: Mandatory Projectmanager: Important SLED-11: New Priority Requester: Mandatory - SLES-11: New + SLES-11: Done Priority Requester: Mandatory Requested by: coolo(a)novell.com Partner organization: openSUSE.org Description: Our (openSUSE) statistics show that most of our users are not native english speakers. So I'm blindly assuming they do not have a english keyboard either and do not live in an english speaking timezone. So I want the first page to be not just the language in a blue box, but to have _one_ installation page with language, timezone and keyboard selection. These selections should depend on each other, so depending on where I click first the others change. To have a good looking addon, I picture the timezone selection as picture and not as fullscreen list boxes. Discussion: #1: coolo(a)novell.com (2007-11-09 11:48:30) An additional note, feature #302955 is related (split translations out of installation system). #2: jsrain(a)novell.com (2007-11-09 13:27:05) Isn't it easier for users who do not speak English to have the first dialog really as simple as possible (since they cannot read it)? Having just one selection box leads them straight where they need to get; I guess that most of them use mouse for installation, so keyboard is not an issue either... Also, we already have a support in isolinux to select language; then the first dialog is skipped. #3: coolo(a)novell.com (2007-11-09 14:13:14) If isolinux provides a language, then the page is not worse than the timezone page is now. Just that it also allows to change the language after the fact. If users do not grasp english _at all_, they will have a hard time booting the installation off the CD. So I would blindly assume that users have no problem with selecting Deutsch, русский or čeština when presented with a list even if they do not understand the exact context. And when next to that list is even a graphical presentation of the world, most will be able to select the part of the world they live in. #4: evamaria.fuchs(a)novell.com (2007-11-09 16:00:35) I think for the secondary target market of opensuse (first time user, home user)an installer wizard that consists of a series of screens would be convenient. Basically it's preferable that language-, time-zone- and keyboard- selection depend on each other so that modifying one will effect the others. But - as I prefer a picture (e.g. a rotating globe) for time- zone selection - sticking them together in one screen would clutter the whole thing up. #5: coolo(a)novell.com (2007-11-15 13:01:50) after some discussions with Eva, I want to reexpress my request: I want the language selection to be on one page together with license and a welcome text and the timezone dialog to be graphical and a proposed keyboard layout associated to the language from the first page. The license text doesn't have to be visible in full beauty. I talked with the lawyer and what I got was: it's ok if the license can be read, it doesn't have to optimized for scrolling. I'll work on a mockup. The challenge is that we might need a slightly different work flow for ncurses, but I think popups are ok for it. So you can write UI code, that either fills a special widget or opens a popup. #6: coolo(a)novell.com (2007-11-18 13:53:57) (reply to #5) Danger Mouse! I'm very far from a capable mockup designer. But here is my show: http://ktown.kde.org/~coolo/Namenlos.png #7: coolo(a)novell.com (2007-11-18 13:54:45) (reply to #6) Ciaran, just to verify: is this way to present the license ok? #9: cfarrell(a)suse.de (2007-11-19 08:51:13) (reply to #7) Provided that we maintain the status quo with regard to not proceeding with the installation until the user actually accepts the license. #8: coolo(a)novell.com (2007-11-18 14:39:45) (reply to #6) mocking up the timezone page, I leave to the interested reader. For reference: this is how unbuntu's installer looks like: https://help.ubuntu.com/community/GraphicalInstall?action=AttachFile&do=get… I would make the map a little smaller and do not show a region and not the name of the timezone again, but rather have the value of the combobox fill in what we have now as Europe/Berlin. Because I want a "Keyboard: English" with a little test field in there. But that is to be discussed. The main goal is to have a graphical selection instead of these fullscreen list boxes. #10: michl(a)novell.com (2007-11-19 13:28:22) Mockup looks good. And the whole thing should simplify and shorten the installation process. #11: jsrain(a)novell.com (2007-11-19 16:57:23) The timezone dialog looks good to me, however, we should not present the other one in the current form. Even if we have a different dialog for NCurses, we still must take care of Qt with the resolution of 800x600. With the current font size, the text itself will not fit into the screen if it is 800x600. Also consider the license - if one wants to read it, he wants to read a reasonable part of the license without scrolling - and not to scroll every 3rd line. IMO this suggestion puts the usability a huge step back #12: coolo(a)novell.com (2007-11-19 18:23:04) (reply to #11) damn, fate crashed on my comment ;( Again: I'm not a good designer But as a matter of fact: we do not design the default screen estate for reading the license, but of course a better design can add a popup to read the full text in full screen. #14: locilka(a)novell.com (2007-11-29 13:10:32) Additional step to help user understand where he is and what he can do there is to remove a [Show Release Notes] button and place that button to a Welcome Dialog only. The button doesn't need to occupy installation wizard screen all the time, it often rather confuses users. Frankly, this wasn't my idea but I found it useful :) ;) #15: jsuchome(a)novell.com (2007-12-20 16:19:25) Proposal of timezone dialog with a map: http://w3.suse.de/~jsuchome/screenshots/yast2-timezone-wordmap-zoomed.png BTW, it may not have a sense to offer keyboard configuration together with timezone. Keyboard layout is currently decided according to selected language, so it may better fit together with language. But the language dialog could get eventually too crowded. #16: coolo(a)novell.com (2007-12-22 14:05:24) new screenshot for the first page (I tried ycp): http://ktown.kde.org/~coolo/yast7.png Some icons and some more text would help the design I'd think. #17: coolo(a)novell.com (2008-01-08 12:40:13) http://en.opensuse.org/Image:Yast8.png is Martin's counter proposal. This one needs icons to differ the combo boxes though, but I believe a keyboard and an UN flag should make this obvious enough. #18: locilka(a)novell.com (2008-01-10 15:24:31) (reply to #17) BTW: This complex dialog will not be part of yast2-country (or similar) but directly yast2-installation because it contains more than just defining the language and keyboard settings. License handling needs to be reworked. #19: jsuchome(a)novell.com (2008-01-23 09:37:39) (reply to #18) Well, OK than. I expect you will ask for creating some API of Language (and maybe Keyboard) module, because current one probably is not sufficient. The API should be used instead writing whole stuff again separately, so we don't have the language handling on more places. #20: locilka(a)novell.com (2008-01-28 11:22:59) (reply to #19) Yes, Language API would probably help a lot. Please, propose, what you could create considering the default state at http://svn.opensuse.org/svn/yast/trunk/installation/src/clients/inst_comple… For instance, generating the combo boxes for language and keyboard selections might be moved to the API (I saw some functions in the current API though). The current implementation has been done in a hurry before the alpha deadline, it needs to be polished. Feel free to change it directly, it's open source. #21: jsuchome(a)novell.com (2008-01-28 11:32:01) (reply to #20) I agree, currently the API for generating the widget contents is needed, maybe that's all. I have to check it. #22: locilka(a)novell.com (2008-02-01 04:09:18) New "where am I page" with Language, Keyboard, and License will be in 11.0 Alpha2. + #23: locilka(a)novell.com (2008-02-27 11:10:18) (reply to #22) + Done in openSUSE 11.0 Alpha2 (and later). + There were some bugfixes and internal changes though... -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=302957

1 0

[Fate 302955] Split translations out of installation system
by fate_noreply＠suse.de 26 Feb '08

26 Feb '08

Feature changed by: locilka Feature #302955, revision 47 Title: Split translations out of installation system openSUSE-11.0: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: coolo(a)novell.com Partner organization: openSUSE.org Description: The translations of yast are the biggest part of the installation image. These should not be part of the image, but should be pulled in from the product media as the user selects them. Discussion: #1: jsrain(a)novell.com (2007-11-09 13:18:17) Duncan, we will need a Linuxrc support for this. Can Steffen look into this feature? What comes to my mind is: Linuxrc needs to download and mount the language image for the language which user selected in bootloader menu (or English as fallback) Linuxrc needs to provide a support (eg. a script) which YaST can call when Language changes and downloads and "mounts" the new translation image It is questionable whether it should be YaST or Linuxrc who makes checks if the asked image is already downloaded, IMO it should be Linurc... #2: snwint(a)novell.com (2007-11-09 14:08:01) (reply to #1) I don't see linuxrc involved at all. YaST can just donwload he required files. Doesn't look that tricky to me. #3: jsuchome(a)novell.com (2007-11-09 14:29:36) (reply to #2) Maybe, but I do not know how. Lukas, don't we have some API in yast2- installation for that (copying target package from media to inst-sys, if I understand it correctly)? #4: snwint(a)novell.com (2007-11-09 14:32:40) (reply to #3) We've had exactly that discussion when we talked about loading the licenses. I think now is a good time to fix yast. I really don't see why other programs have to download various files for yast when yast could as well do it itself. And when this means doing the repo init earlier, then, well, do it earlier. #5: jsrain(a)novell.com (2007-11-09 15:02:22) (reply to #4) YaST can only fetch data from instlalation sources. Inst-sys can come from completly different location than installation sources do. YaST has no information where to get these images from. YaST would have to reimplement getting data from all kind of locations on its own (it cannot use libzypp, since at the location, there needn't be any valid source. That's why I'd like to reuse functionality which Linuxrc already has. #7: coolo(a)novell.com (2007-11-16 11:42:17) (reply to #5) Duncan, is it feasible to make the download functionality of libzypp seperate from valid sources. E.g. RepoManager::download(theurl_I_got_from_linuxrc, "/suse/translations/de.tar"); #10: dmacvicar(a)novell.com (2008-01-22 18:35:02) (reply to #7) Yes, MediaSetAccess or even MediaAccess can be used to get a file directly from an Url. The design is layered, MediaAccess sits on top of MediaManager(curl, iso, etc), MediaSetAccess on top, adding multiple media and media changing support, and RepoProvideFile on top, using the repos urls and trying different mirrors. There is also Fetcher which also sits on top of MediaSetAccess which provide queues and using already downloaded files. I think it is already used in YaST, YaST does transfer the content file from media independently from ZYpp. #6: locilka(a)novell.com (2007-11-09 16:54:01) (reply to #3) As already written by snwint, there is no way how to download anything from sources before they are initialized. So: no, there is no Installation API for that. As there can be an installation-(zypp)-source and a different inst-sys, Installation could either initialize the source as soon as possible but it still wouldn't know where to download inst-sys extensions. On the other hand, Linuxrc doesn't know which translations will be needed. So maybe inst-sys could provide some functionality (API) for downloading these extensions and merging them (downloaddir + adddir), YaST could then use that API. Just an idea... #8: michl(a)novell.com (2007-11-29 12:46:53) We should come down to tier1 languages here. #11: locilka(a)novell.com (2008-01-28 19:06:03) (reply to #9) According the forwarded mails, the Installation framework should call Get InstsysURL and RepoURL from /etc/install.inf (and combine them with a file/localization location to $url_to_download_file_from) /lbin/wget -v $url_to_download_file_from $path_to_save_file_to mkdir /mounts/localization mount -o loop $path_to_save_file_to /mounts/localization adddir /mounts/localization / Where (dir) and under which names will be the localization files (language images) stored? #12: locilka(a)novell.com (2008-01-29 10:39:24) (reply to #11) Snwint: does /lbin/wget check signatures of that file or does inst-sys provide some functionality I could use to check them? #14: snwint(a)novell.com (2008-01-29 11:06:11) (reply to #12) No it doesn't check them. But their SHA1sum will appear in /content. #13: snwint(a)novell.com (2008-01-29 11:03:05) (reply to #11) The language images are named root.XXX where XXX is XXX in yast2-trans- XXX. #15: locilka(a)novell.com (2008-02-04 07:25:10) (reply to #13) Stano's idea: For a better user experience, let's have all translations for the first dialog available from the very beggining (it's actually installation.mo ). In other words, installation textdomain should be still in the inst-sys-base, other text-domains in squashfs images. Download the language squashfs inst-sys extension after clicking on [Next] in the first dialog. That would make it visually faster. #16: locilka(a)novell.com (2008-02-04 07:58:54) (reply to #15) Ah, I've found that having installation.mo in the base inst-sys is currently the only way to avoid translation errors. YaST uses gettext for translating messages. The very first dialog using a gettext functions (e.g., initializing installation) is called even before the translation file is downloaded. In this case, gettext wouldn't find any translation. It would return untranslated message and also remember that there was no translation file available. After the installation adds the translation file, gettext would ignore it (This is known behavior since OES2 its Add-On integration into SLES10 SP1 workflow). #19: locilka(a)novell.com (2008-02-04 11:59:10) (reply to #16) Problem solved. According to snwint, the initial root.$LANG file is downloaded by Linuxrc, long time before YaST does anything. #17: locilka(a)novell.com (2008-02-04 08:06:35) (reply to #13) Where do we expect the root.$LANG files? On the installation repository or in the inst-sys? Consider this situation: RepoURL: nfs://install.suse.cz/11/?device=eth0 InstsysURL: nfs://miracle.suse.cz/11i/inst-sys/?device=eth0&aaa=bbb I assume that for de_DE URL nfs://miracle.suse.cz/11i/root.de_DE? device=eth0&aaa=bbb should be used but is that correct? Why not nfs: //install.suse.cz/11/boot/<arch>/root.de_DE?device=eth0 ? #18: snwint(a)novell.com (2008-02-04 14:22:41) (reply to #17) The files are taken from miracle because they should somehow match the other instsys files. #20: locilka(a)novell.com (2008-02-04 12:00:39) (reply to #13) Is there any possibility to list these (root.XX, root.xx_XX, ...) files? Because I haven't found any both systematic and valid solution. #21: snwint(a)novell.com (2008-02-04 18:07:19) (reply to #20) No idea; I'm using yast2-trans-allpacks when I build the instsys. #22: locilka(a)novell.com (2008-02-04 12:16:54) (reply to #21) This shows the list of $somehow supported translations ls -1 /usr/lib/YaST2/trans | sed 's/\.status//' however it is not ideal. #23: locilka(a)novell.com (2008-02-04 12:27:27) (reply to #22) A simple solution would be to introduce a new entry into the content file, e.g., SUPPLANGS . This variable would contain (space-separated) list of supported languages in YaST (all ${LANG}s for all root.$LANG files). Rudi, could you, please, add it? #24: snwint(a)novell.com (2008-02-05 10:07:12) (reply to #23) All root.xxx are already in content as they are sha1-summed. #25: locilka(a)novell.com (2008-02-05 04:34:37) (reply to #24) But their SHA1 is still not checked by the installation (YaST) when downloaded. It's in my TODO. #26: snwint(a)novell.com (2008-02-05 10:49:20) (reply to #25) Maybe. But it basically is the list you asked for in comment 23. Or not? #27: locilka(a)novell.com (2008-02-05 05:29:03) (reply to #26) It basically is the list I asked for for, but it doesn't contain the informative value that defines: hey! these languages are supported, use these files (...). For instance file, root.fonts , should be also signed and partly matches the pattern but fonts is not a language. And there might be several files later... So, I don't think this would work. #28: locilka(a)novell.com (2008-02-07 16:32:53) (reply to #25) I've found that SHA1 sum for checking the downloaded files cannot be computed :( Snwint: It seems that sha1sum is not part of the inst-sys. Linuxrc seems to check the SHA1 itself (sha1.c). What should I use? What would be the best solution? Integrate sha1sum into the inst-sys? #29: snwint(a)novell.com (2008-02-07 18:08:27) (reply to #28) Sure. I'll add it. #35: jsuchome(a)novell.com (2008-02-18 13:50:00) (reply to #23) What is the reason for SUPPLANGS when we already have LINGUAS? #36: locilka(a)novell.com (2008-02-18 14:12:17) (reply to #35) Because LINGUAS were in use already. And they currently DO NOT reflect the status of *all supported languages*. Anyway, the SUPPLANGS tag hasn't been added and installation uses a fallback that checks all trans-stats and takes the list of supported languages from there (which works well). /** * check if selected language has support on media (F301238) * show a warning when not */ define void check_languages_support (string selected_language) { string linguas = (string) SCR::Read (.content.LINGUAS); if (linguas == nil) { y2warning ("No LINGUAS tag defined in content file"); return; } y2milestone ("content LINGUAS %1", linguas); list <string> all_linguas = splitstring (linguas, " "); string language_short = splitstring (selected_language, "_") [0]:""; if (!contains (all_linguas, selected_language) && !contains (all_linguas, language_short)) { y2milestone ("Language %1 is not fully supported", selected_language); // popup message Popup::Message (_("Only minimal support for the selected language is included on the media. Add the Language Add-On CD as an additional repository to get better support for this language.")); } } #37: jsuchome(a)novell.com (2008-02-18 14:23:46) (reply to #36) I can read the code and I know that LINGUAS is used. Still, I think the meaning of SUPPLANGS is the same. Or it should be if it currently is not. #38: locilka(a)novell.com (2008-02-18 14:36:09) (reply to #37) I'm afraid that it is not correct. According to the soruce code, LINGUAS contain list of languages that are fully supported and if user selects language, that is NOT listed in LINGUAS he/she/it is warned. On the other hand SUPPLANGS (as it was requested) should have contained list of all languages supported in YaST (in other words: list of languages in a separate squashfs images that can be used as a plugin to the installation). That's why we can't reuse LINGUAS if we use them for this check. But, of course, as far as I know, using the LINGUAS should be replaced with getting the information from trans-stats files: less than XY% means -> language not fully supported. (Stano?) #39: jsuchome(a)novell.com (2008-02-18 14:52:12) (reply to #38) Well, if we want to know list of all languages supported in YaST, we do not need other variable in content file, we know this from YaST already: these are the languages offered in the language selection. And checking for insufficient languages support (now done against LINGUAS) and insufficient translation treshold (trans-stats) is a different thing: certain language could be only on Add-On (=not in LINGUAS), but it could be 100% translated and vice versa. #40: locilka(a)novell.com (2008-02-18 15:04:28) (reply to #39) Please, try to solve reasonable ammount of features and bugs at once. This feature is about translation split (out of the installation system). If some languages are additionally supported by some Add-On product, installation will not be able to add them on-the-fly (yast translations for inst-sys). Language Add-On might contain some additional packages but that's all. It will not have any effect on the inst-sys. If this is all about not using SUPPLANGS, please, change the client that tries to read it, to use the Language (or whatever) module. SUPPLANGS in not (and probably will not be) added. Installation currently uses trans-stats to find out all languages supported by the inst-sys. It can be changed to use Language module directly (if it provides the very same information). That's a little implementation detail. #41: jsuchome(a)novell.com (2008-02-18 15:12:26) (reply to #40) Sure. I was not trying to solve anything, I asked why is it needed. Based on your information I concluded that it is not. I only wrote about Add-Ons to describe the distincition with LINGUAS and trans-stats usage (= answer to as far as I know, using the LINGUAS should be replaced with getting the information from trans-stats files... ) #30: locilka(a)novell.com (2008-02-08 13:36:08) For jsuchome/country (possibly-buggy behavior reported by jsuchome): If user selects another language in the 'installation overview' (former 'proposal'), language selection needs to call this: if (Stage::initial()) { WFM::call ("integrate_translation_extension", [$["requested_language":language]]); } You should call it before Language::Set (language) is called. This is used only in inst-sys /Stage::initial()/, client integrate_translation_extension has been added to yast2-installation- 2.6.18 #31: jsuchome(a)novell.com (2008-02-08 13:52:32) (reply to #30) Actually, I would like to have this call (+all the checks when it is necessary of course) inside Language::Set call, so that no code that wants to change the language needs to care about this. #32: locilka(a)novell.com (2008-02-08 14:12:56) (reply to #31) Hmm, that sounds reasonable... We had better move the client from installation to country then... #42: jsuchome(a)novell.com (2008-02-26 12:44:14) (reply to #30) I moved the functionality of "integrate_translation_extension" into Language::Set. Available in yast2-country-2.16.11 . I hope this is all for this feature, see you in bugzilla. + #43: locilka(a)novell.com (2008-02-26 14:11:33) (reply to #42) + We've agreed on moving the functionality to module Language because of + the transparency for all usage. It's easier to call Language::Set() + which handles all the needed stuff than calling some ycp script with a + parameter. It's less error-prone and also faster. + Anyway, the package is yast2-country-data (not yast2-country (typo) - + that would bring another circle of dependencies again). I've already + adjusted the installation spec file. -- SUSE Feature Tool: http://partnerfate.suse.de/?rm=feature_show&id=302955

1 0