March 2016 - YaST Development - openSUSE Mailing Lists

[yast-devel] New home for storage-ng projects
by Ancor Gonzalez Sosa 07 Mar '16

07 Mar '16

If nobody is against, tomorrow I will copypac this two packages from home:aschnell:storage-redesign to YaST:storage-ng and will configure ci.opensuse.org to commit there every change in the corresponding github repos. yast2-storage-ng libstorage-ng In addition to that, I will also copypac swig for the time being, although I'm not sure if we are currently following the right approach or it should be a link to openSUSE:Factory/swig (instead of a copy). So if you don't like the new location, speak up now. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

3 2

[yast-devel] Yast CI jobs switched to webhooks
by Ladislav Slezak 07 Mar '16

07 Mar '16

Hi all, I have switched all yast-*-master jobs at https://ci.opensuse.org to use github webhooks instead of active polling. Advantages: 1) Faster build start - the polling had 5 minutes interval, it could take up to 5 minutes to start the build after a change at the Github repository. Now it should start (almost) immediately. 2) Less network traffic and decreased load for the Github servers (5 minutes polling interval sounds good, but with about a hundred YaST repositories we did a ping to Github roughly every 3 seconds and in vast majority cases is no change in the repo.) It should work without any problem, I have already used that is some repositories for some time. But if you find a problem with the new setup just ping me. -- 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

2 3

[yast-devel] Pending Pull Requests
by yast-ci＠opensuse.org 07 Mar '16

07 Mar '16

This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet. Pending requests in repository yast-autoinstallation: - Use /proc/uptime instead of system time while waiting for services restart (9 days) https://github.com/yast/yast-autoinstallation/pull/197 - Fix install rules SLE 12 GA (38 days) https://github.com/yast/yast-autoinstallation/pull/190 - [Review] Request from 'schubi2' @ 'yast/yast-autoinstallation/review_160113_bug_955878_merged_with_sp1' (52 days) https://github.com/yast/yast-autoinstallation/pull/179 Pending requests in repository yast-core: - Optionally build with Clang instead of GCC (via bcond_with clang). (10 days) https://github.com/yast/yast-core/pull/106 Pending requests in repository yast-country: - Some changes in the tumbleweed mappings (bsc#942899 and bsc#942896) (40 days) https://github.com/yast/yast-country/pull/61 - Ensure ntp is installed (when Install Recommended Packages is off) (152 days) https://github.com/yast/yast-country/pull/55 Pending requests in repository yast-installation: - Fix macro expansion in %post comment (6 days) https://github.com/yast/yast-installation/pull/341 - Poc recover values (132 days) https://github.com/yast/yast-installation/pull/319 Pending requests in repository yast-network: - [WIP] Added subclass for recognize InfiniBand cards (bsc#903190) (10 days) https://github.com/yast/yast-network/pull/383 Pending requests in repository yast-snapper: - [DO NOT MERGE] Added snapshot Class with strategy pattern. (93 days) https://github.com/yast/yast-snapper/pull/40 - Cleanup and delete multiple snapshots at once (#bsc#956143). (95 days) https://github.com/yast/yast-snapper/pull/39 Pending requests in repository yast-storage: - Add option to disable swap creation (39 days) https://github.com/yast/yast-storage/pull/182 - Ported support for LVM proposal setting from SP1 to Master (10 days) https://github.com/yast/yast-storage/pull/177 - Propose /boot for encrypted root on PowerPC (75 days) https://github.com/yast/yast-storage/pull/155 Pending requests in repository yast-testsuite: - skel: runtest.sh: Set Y2DIR to a sensible default value (10 days) https://github.com/yast/yast-testsuite/pull/13 Pending requests in repository yast-yast2: - Cleanup NetworkInterfaces.Read (31 days) https://github.com/yast/yast-yast2/pull/433 - Count test coverage more accurately (10 days) https://github.com/yast/yast-yast2/pull/426 Pending requests in repository yast-auth-server: - Drop ca mgm (46 days) https://github.com/yast/yast-auth-server/pull/21 Pending requests in repository yast.github.io: - Add some documentation about submit requests (100 days) https://github.com/yast/yast.github.io/pull/55 Pending requests in repository aytests-tests: - [do not merge] Installation rules (23 days) https://github.com/yast/aytests-tests/pull/12 -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel][a11y][u9y] video mode/text size control at installation
by Felix Miata 06 Mar '16

06 Mar '16

Where's YaST's "knob" for making screen text bigger during installation? F3 is useless for the GUI. One size does not and cannot fit all!!! Native video mode may be best from a designer perspective, but for many people, results from native just aren't usable. Some people need bigger screen objects, and are aware lowering resolution is a way to get what they need. Is https://en.opensuse.org/SDB:Linuxrc relatively complete? If there's anything there directing the installer to use a particular video mode, I'm missing it. Strings "video" and "driver" are both absent. As I virtually always install using HTTP started from Grub, which preconfigures host and netcfg, any more I have minimal familiarity with what's in the DVD's menu WRT F3 video, which is why I went to that web page looking. I often go there for other reasons. Also because of the absent familiarity, I did several NET initializations to take screenshots, to make sure my eyes weren't deceiving me: yastI-grubShttp-cmdlineVideo1024x768dvi.png yastI-grubShttp-videoDefaultDVI.png yastI421F3-800x600on1920x1080-dvi.png yastI421F3-1280x1024on1680x1050.png all @ http://fm.no-ip.com/SS/Suse/YaST/421/ All are at the display's EDID native mode, not the cmdline video= specified mode. Apparently that desired mode is only utilized by the vttys, not Xorg's modesetting driver: xorg.0.log-421Installation-video1024x768ignored xorg.0.log-421installation-DefaultVideo xorg.0.log-NET421Installation-F3-800x600on1920x1080 xorg.0.log-NET421installation-F3-1280x1024on1680x1050 all @ http://fm.no-ip.com/Tmp/SUSE/421/ TW doesn't appear to work any differently: http://fm.no-ip.com/SS/Suse/YaST/TW/yastItw160305F3-800x600on1680x1050.png http://fm.no-ip.com/Tmp/SUSE/Xorg/xorg.0.log-twInstallation0303-F3-800x600o… Those are all on Intel gfx, but results are same with ATI: http://fm.no-ip.com/SS/Suse/YaST/TW/yastItw160305F3-radeon1024x768on1680x10… http://fm.no-ip.com/Tmp/SUSE/Xorg/xorg.0.log-twinstallation0303-F3-radeon10… Must the GUI use the modesetting video driver instead of an Intel, Radeon or Nouveau driver? Xorg by default picks up specified video= from kernel, which gets it via cmdline, and uses it for users of the Intel driver. Do I need to file a BOO bug to get the modesetting driver to pick up and use video= from the installation kernel's cmdline? I didn't find any on point. Maybe because of last paragraphs on https://lists.opensuse.org/opensuse/2016-03/msg00309.html one will already have been filed by someone else by Monday AM. Those with 3840x2160 or other high density screens are apparently in big trouble trying to install. -- "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

1 0

[yast-devel] Pending Pull Requests
by yast-ci＠opensuse.org 04 Mar '16

04 Mar '16

This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet. Pending requests in repository yast-autoinstallation: - Use /proc/uptime instead of system time while waiting for services restart (6 days) https://github.com/yast/yast-autoinstallation/pull/197 - Fix install rules SLE 12 GA (35 days) https://github.com/yast/yast-autoinstallation/pull/190 - [Review] Request from 'schubi2' @ 'yast/yast-autoinstallation/review_160113_bug_955878_merged_with_sp1' (49 days) https://github.com/yast/yast-autoinstallation/pull/179 Pending requests in repository yast-core: - Optionally build with Clang instead of GCC (via bcond_with clang). (7 days) https://github.com/yast/yast-core/pull/106 Pending requests in repository yast-country: - Some changes in the tumbleweed mappings (bsc#942899 and bsc#942896) (37 days) https://github.com/yast/yast-country/pull/61 - Ensure ntp is installed (when Install Recommended Packages is off) (149 days) https://github.com/yast/yast-country/pull/55 Pending requests in repository yast-installation: - Poc recover values (129 days) https://github.com/yast/yast-installation/pull/319 Pending requests in repository yast-network: - [WIP] Added subclass for recognize InfiniBand cards (bsc#903190) (7 days) https://github.com/yast/yast-network/pull/383 Pending requests in repository yast-snapper: - [DO NOT MERGE] Added snapshot Class with strategy pattern. (90 days) https://github.com/yast/yast-snapper/pull/40 - Cleanup and delete multiple snapshots at once (#bsc#956143). (92 days) https://github.com/yast/yast-snapper/pull/39 Pending requests in repository yast-storage: - Add option to disable swap creation (36 days) https://github.com/yast/yast-storage/pull/182 - Ported support for LVM proposal setting from SP1 to Master (7 days) https://github.com/yast/yast-storage/pull/177 - Propose /boot for encrypted root on PowerPC (72 days) https://github.com/yast/yast-storage/pull/155 Pending requests in repository yast-testsuite: - skel: runtest.sh: Set Y2DIR to a sensible default value (7 days) https://github.com/yast/yast-testsuite/pull/13 Pending requests in repository yast-yast2: - Cleanup NetworkInterfaces.Read (28 days) https://github.com/yast/yast-yast2/pull/433 - Count test coverage more accurately (7 days) https://github.com/yast/yast-yast2/pull/426 Pending requests in repository yast-auth-server: - Drop ca mgm (43 days) https://github.com/yast/yast-auth-server/pull/21 Pending requests in repository yast.github.io: - Add some documentation about submit requests (97 days) https://github.com/yast/yast.github.io/pull/55 Pending requests in repository aytests-tests: - [do not merge] Installation rules (20 days) https://github.com/yast/aytests-tests/pull/12 -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel] Let's Move Sprint X Review/Planning
by Lukas Ocilka 03 Mar '16

03 Mar '16

Hi, I'd like to ask for postponing review (18) and planning (19) meetings planned for April 26th and April 27th. Me and Jiri are both at offsite from April 21st till April 27th. For that reason, I'd love to move it this way: * Review on Tuesday 26th --> Thursday 28th * Planning on Wednesday 27th --> Friday 29th Anyone against this or having a better idea? Thanks in advance Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux https://en.wikipedia.org/wiki/Scout_Promise#Czech_Republic http://www.scouting.org/Visitor/WhyScouting/ServingOthers.aspx -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel] Yast and rubygems dependencies
by Josef Reidinger 03 Mar '16

03 Mar '16

Hi, as disclosured by recent openqa testing, yast have to fix dependency on rubygems to always use system ruby ABI ( as it use system ruby and gems with different ruby ABI cannot be used together). So if you add any rubygem then please fix ruby ABI. way how to specify it: Requires: rubygem(%rb_default_ruby_abi:cheetah) instead of plain Requires: rubygem(cheetah) Thanks Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel] Rspec as specification
by Josef Reidinger 03 Mar '16

03 Mar '16

Hi, as there is in last days some discussion how rspec can be used as specification or not and I would like to document how bootloader do its proposal, so I take it as oppurinity to write it in RSpec. Output for better formatting is placed to pastebin http://pastebin.com/raw/8YhuWwVi Please ignore for now typos. I am more interested if it is readable for you as specification how bootloader is proposed. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

7 12

[yast-devel] Concepts in Storage?
by Martin Vidner 03 Mar '16

03 Mar '16

Hi! I had long managed to do without it, but it seems I will have to learn about Storage code... Now I know: Device Graph are the things, Action Graph are the transformations, Proposal is the main goal for the user. I expect that there are some details on a lower level, like Disks, Partitions, Filesystems, Mkfs commands. What are the other important concepts? Is a Proposal just one Action Graph? If not, what is between them? -- Martin Vidner, YaST Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

1 0

[yast-devel] The Business Case for Y-Storage - Proposal vs. Device Graph
by Stefan Hundhammer 03 Mar '16

03 Mar '16

Following up on the "Refactoring madness" thread and an IRC discussion; I had written lately: "this is an approach I don't like at all because it focuses on the wrong thing: All that stuff is not about creating device graphs. We are not in the business of making or selling device graphs. Device graphs are just a tool for what we really intend to do. Concentrating on an irrelevant (or, to put it less harshly, behind-the-scenes) tool is most misleading for anybody looking at that code." I was asked to elaborate that point further, so here we go: What is the point of what we are doing in that new yast-storage-ng? This is really all about making a storage proposal for our installation workflow; this is the main purpose of it all, with more specialized issues like the expert partitioner aside. In most of the history of YaST2, we had the concept of providing the user with a useful, reasonable "proposal" for each aspect of the Linux installation. It was always intentionally called "proposal" because it is not set in stone; the user can always change it if it doesn't fit his needs. So we've been doing some calculations based on hardware probing, based on product parameters (control.xml), based on guessed values for every aspect of the installation: For the bootloader, for the software selection, for the desktop etc. etc., and for storage: What partitions to remove or to resize to make room for Linux, what new partitions and file systems to create, where to mount them. So the term "proposal" is a well-known concept in the YaST installation for YaST developers as well as for other people in SUSE R&D, including product and project managers, and even for some advanced users. So, when looking through the installation code, I would expect that to be somehow reflected in the code; I'd expect a class "StorageProposal" somewhere, preferably with a main method 'propose()'. And it used to be like that in my first version of that new storage proposal. But not for long: It was changed very soon to a class "DevicegraphGenerator". There is now also a class "RefinedDevicegraph". One thing that is no longer present, though, is anything with "Proposal" in the name. To me, this is not only not self-explanatory (as good code should be), it is outright confusing. Anybody searching for the place where a storage proposal is made will have to do a lot of grepping to find where it happens, and so far every was vers much surprised (to put it mildly) where this was. That's misleading IMHO. Device graphs are a useful tool in that context, but just that: A tool. They are not the central part around everything revolves, at least not from the perspective of a developer using that part. That's why I had written that we are not in the business of making or selling device graphs, we are in the business of making useful proposals. I miss the whole concept of proposals here. There is only one function in the DevicegraphGenerator called proposal(), and even that was only named like this after several people had agreed that run() is not a good name, in particular when you have a run() function in several classes (good luck finding the right one with 'grep'!). So, what we are doing now is to put very much emphasis on an implementation detail while omitting the well-known concept. Kind regards -- Stefan Hundhammer <shundhammer(a)suse.de> YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

3 3