September 2013 - YaST Development - openSUSE Mailing Lists

[yast-devel] Fixing yast2-slide-show for SLE11 SP3
by Karl Eichwalder 16 Sep '15

16 Sep '15

I want to fix yast2-slide-show for SLE11 SP3. Which git commands do I have to use, please? Thus far, I have checked out trunk only. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 7

[yast-devel] RFC: Maintenance branch for 13.1
by Josef Reidinger 31 Oct '13

31 Oct '13

Hi, as factory is already splitted to 13.1 and we have bunch of quite aggresive changes on stack like rake build system, rubify code or core changes, I think we should do fixes for 13.1 in maintenance branch following common naming schema[1] - openSUSE-13_1 Any comments, counter-proposals or complains? Josef [1] https://en.opensuse.org/openSUSE:YaST_SVN_to_GIT#Conventions ( yes, location sucks and we plan to improve documentation ) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 8

[yast-devel] YaST installer - the future development (for 13.2/SLE12, aka "the new installer")
by Ladislav Slezak 18 Oct '13

18 Oct '13

Hi all, The SUSE YaST team started developing some major YaST features for SUSE Linux Enterprise 12 (SLE12) installer and we would like to include these features in the next openSUSE-13.2 release. The features are mainly about making the installer easier and to simplify the installation workflow. We will not create a completely new installer from scratch (that would need too much time and manpower), we will reuse the existing functionality as much as possible, the current installation framework is quite flexible (e.g. the installation steps are defined in external control.xml file). Here is the summary of the main goals: - Remove the second installation stage (started after reboot), configure the system completely just in one stage, after finishing the installer the freshly installed system must be ready to use. - It should be possible to NOT install the Yast installer itself into the target system to make it smaller (except when firstboot or some complex AutoYast setup is used, then the installer will be needed). - Separate the installer into 3 basic steps (collect data, install, apply config), make the steps replaceable by 3rd party applications. - It should be possible to use the installer just for configuring the installation and exporting the setup into a file (without performing the actual installation). The exported file could be then used to install other system(s). (Like AutoYast does, the new installer will contain some AutoYast functionality). - It should be possible to alternatively deploy already existing appliance image (provided by user) instead of installing from RPMs. - Simplify the installation workflow, auto-configure what's possible, advanced setup (NIS, LDAP, Kerberos...) should be done in installed system. - Use new possibilities for autodetection (e.g. GeoIP for language / time zone proposal). - Works on a system with 512MB RAM only, we also keep in mind the resources needed for the installer. More details about the current proposal will be published later. We would like to discuss these ideas in the openSUSE installer context so the new installer brings also interesting and important features for the openSUSE community users. Ladislav -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak(a)suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

7 19

[yast-devel] Jenkins is Green!
by Martin Vidner 01 Oct '13

01 Oct '13

Look! All ;-) jobs are green http://ci.opensuse.org/view/Yast/ http://ci.opensuse.org/view/Yast/job/yast-devtools-master2/88/console was solved by rebuilding after pushing https://github.com/yast/yast-devtools/commit/1f9e06c2d1ae3d941557aa0fc661a4… It also failed on http://ci.opensuse.org/view/Yast/job/yast-devtools-master2/89/console and fixing that required installing obs-service-format_spec_file. No big deal except that pulls in obs-service-source_validator which wants the C compiler, 190 MB, WTF, JFYI. I wonder how far we get in https://build.opensuse.org/project/monitor/YaST:Head -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

2 2

[yast-devel] devtools problem
by Arvin Schnell 01 Oct '13

01 Oct '13

Hi, AFAIS the check for ycpc has been removed from yast2-devtools so YCPC is no longer defined in Makefile.am. But it's still used in /devtools/admin/Makefile.am.common. As a result I currently cannot run "make pckage-local" for yast2-storage. ciao Arvin -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 1

[yast-devel] Runlevel is obsolete term
by Felix Miata 30 Sep '13

30 Sep '13

7th main menu item "Default Runlevel" language on http://fm.no-ip.com/SS/Suse/yast2-000.png was technically obsolete as of 12.3 (IIRC), but if not then, it certainly is now. Has anyone made plans to update it before 13.1GA? Need I file a bug? It might be good enough for the time being at least to s/Default Runlevel/Default Services Configuration/. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 1

[yast-devel] default assignment for yast component in bugzilla
by Josef Reidinger 27 Sep '13

27 Sep '13

Hi, I found quite annoying to have as default assignment bugzilla screening team, that are quite ineffective, which usually result in ask for logs and then assign to yast-maintainers or random people. Annoying part is that it usually takes some time, so if something is broken, we get bug report too late ( usually one release after, so if bug found in M2, we can fix it in M4 ). I think it will be better to have directly as default assign yast-maintainers, so we can quickly proceed to proper developer. I found it especially important for bug reports from factory or next opensuse releases. Is there any reason to have bugzilla screening team? any opinions? Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 4

[yast-devel] openSUSE-13_1 branches created
by Ladislav Slezak 27 Sep '13

27 Sep '13

Hi all, I have created openSUSE-13_1 branches for all relevant Yast packages which are included in openSUSE-13.1 (see the attachment) and also for libyui packages. Use this branch for 13.1 fixes and maintenance updates, the master is now open for Factory/13.2/SLE12 development. That also means do not submit packages from YaST:Head to 13.1. Steps for submitting 13.1 fixes: git checkout openSUSE-13_1 < make a fix, create a pull request to 13.1 branch (not to master!), review PRs, merge... as ususally> make -f Makefile.cvs make package-local osc bco openSUSE:13.1:Update <package> < copy the package sources > < try the build locally > osc build < commit the changes and create a submit request > osc commit osc sr < after you are done with the fix merge it also to master> git checkout master < resolve possible conflicts, likely in VERSION and *.changes > git merge openSUSE-13_1 git push -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/

3 3

[yast-devel] RFC: behaviour on uncaught exception
by Josef Reidinger 26 Sep '13

26 Sep '13

Hi, as YaST currently lives in ruby and we would like to make code nice and benefit from its features it would be nice to change slightly current exception handling on outer bounds. Current exception handling involve only catching exception, logs it and then return false for clients and nil in other cases. I found it quite problematic, because problem is hidden inside logs ( and such behavior makes me crazy in past ) and module looks like working, except that it doesn't work, so it make impression that YaST doesn't work. I propose to change such behavior. If any uncatch exception is catch on bound ( it meands between ruby<->perl or in calling clients ), then Report.Error is used to notify that something goes wrong, with hint that you should report it and maybe message and last two places of exception there? And of course log full exception to log. Advantage of proposal is inform user that something goes wrong, so he doesn't get impression that YaST doesn't work (in case that you want to do something and nothing happened), just that YaST have a bug. We also can be less afraid of using nature ruby syntax and ruby exceptions, as we quickly recognize during testing that something is wrong and we can fix it. Any comments, ideas, counter-proposals? Thanks Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

3 3

[yast-devel] Action Needed: Devtools Cleaning - what tools do you use?
by Josef Reidinger 26 Sep '13

26 Sep '13

Hi, I plan to clean a bit ... ergh, clean almost whole yast2-devtools. At first I would like to mention why I think it is important and what is benefits and then how I would like to do it. Benefit from such cleaning is that for new yast developers is easier to orient what is useful for him and what makes his life easier. Also if we reduce number of tools, we can improve it to be really usefull to all developers. And last but not least, it allows us to identify where tools are just work-arounds that is no longer needed. So how to do it? I start[1] with a cleaning of tools related to ycp or tools that is not touched for years ( there is files not touched for more then 11 years! ). Then I would like to identify what tools are already used by other developers and what is their use case for such tool ( maybe we can enhance different tool to allow it ). I also would like to make logic structure in devtools to tools not intended for humans like rpm macros, generators used by other tools etc, for tools intended for developers that operate on one repo and third category should be current yast-meta project to operate on all yast repos. I also would like to improve README so new developers have easy starting point to introduce which tools we use to make our life easier. So please write which tools from yast2-devtools you use for current master development and how you use it. If you don't write it, there is quite big chance that such tool will be removed. Josef [1] https://github.com/yast/yast-devtools/pull/29 -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 8