June 2017 - YaST Development - openSUSE Mailing Lists

[yast-devel] Pending Pull Requests
by yast-ci＠opensuse.org 15 Jun '17

15 Jun '17

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-add-on: - [WIP] Ask when the added repository is unsigned (bsc#1009127) (127 days) https://github.com/yast/yast-add-on/pull/37 Pending requests in repository yast-bootloader: - Use shared RSpec examples for CWM widgets (86 days) https://github.com/yast/yast-bootloader/pull/414 - don't create grub_installdevice and let perl-Bootloader run grub2-install (71 days) https://github.com/yast/yast-bootloader/pull/413 Pending requests in repository yast-core: - AnyAgent - improved logging to easier find bugs similar to bsc#1030425 (43 days) https://github.com/yast/yast-core/pull/120 Pending requests in repository yast-ldap: - Manipulate system LDAP configuration rather than application LDAP configuration (71 days) https://github.com/yast/yast-ldap/pull/26 Pending requests in repository yast-mail: - [WIP] return back MailTable to yast2-mail module from yast2 module (70 days) https://github.com/yast/yast-mail/pull/25 Pending requests in repository yast-network: - [WIP][Sle15] DNS ay setup written in first stage (5 days) https://github.com/yast/yast-network/pull/520 - routing/firewall: no longer depend on SuSEfirewall2 for IPv4 forwarding (43 days) https://github.com/yast/yast-network/pull/503 Pending requests in repository yast-packager: - [WIP] Ask when the added repository is unsigned (bsc#1009127) (126 days) https://github.com/yast/yast-packager/pull/230 Pending requests in repository yast-security: - [WIP] refactoring autoconverted ruby code into ruby code (63 days) https://github.com/yast/yast-security/pull/40 Pending requests in repository yast-storage: - Propose /boot for encrypted root on PowerPC (70 days) https://github.com/yast/yast-storage/pull/155 Pending requests in repository yast-support: - now SR number can be longer then 11 as we already eat that numbers, s… (8 days) https://github.com/yast/yast-support/pull/12 Pending requests in repository yast-tune: - add docker to sle12sp2 (6 days) https://github.com/yast/yast-tune/pull/23 Pending requests in repository yast-users: - Reduce perl (71 days) https://github.com/yast/yast-users/pull/137 Pending requests in repository yast-vm: - Issue 19 tumbleweed (9 days) https://github.com/yast/yast-vm/pull/20 ERROR: API query limit exceeded -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

Fw: [yast-devel] [PATCH 1/3] Change Apparmor settings to use UI
by Josef Reidinger 14 Jun '17

14 Jun '17

sorry for forwarding, accidentally exclude yast-devel from reply Begin forwarded message: Date: Wed, 14 Jun 2017 08:49:56 +0200 From: Josef Reidinger <jreidinger(a)suse.cz> To: Goldwyn Rodrigues <rgoldwyn(a)suse.de> Subject: Re: [yast-devel] [PATCH 1/3] Change Apparmor settings to use UI On Tue, 13 Jun 2017 16:03:22 -0500 Goldwyn Rodrigues <rgoldwyn(a)suse.de> wrote: > On 06/08/2017 02:33 AM, Josef Reidinger wrote: > > On Wed, 7 Jun 2017 15:38:45 -0500 > > Goldwyn Rodrigues <rgoldwyn(a)suse.de> wrote: > > > >> From: Goldwyn Rodrigues <rgoldwyn(a)suse.com> > >> > >> This is a precursor to use aa-status json profile view. > >> > >> Please note, "Configure" option is left hanging which will be filled > >> in the next patch. > > > > Well, to be honest I found discussion in pull request easier to orientate and also for discussion, but lets comment it here. > > Sorry, coming from the kernel development community, I assumed a bigger > subscription here and hence more eyeballs. I would perform a pull > request in the next review cycle. I know it is still popular in kernel or wine development, but as we live on github, it is easier there, at least to see all comments together. Warning: it is quite addictive :) > > > snip > > > > Just note. It is quite uncommon in yast to react immediatelly in YaST UI. > > Especially consider that user click on "Enable" checkbox and then press cancel. > > This should be done only after click on next, where he confirm that he really want > > to do actions. > > I understand. However, I just followed the design how it exists now. > While I am open to changing the design, it may take me much longer to > learn and implement it. Let's keep it in the next round of changes, but > as a guideline, I would like to have suggestions on how it should look > like. How about yast-firewall? We will have to implement a separate > "Manage profiles". There are more changes I want to introduce there as > well such as multiple/different toggle modes. I know that it is existing design of apparmor and very inconsistent for rest of YaST. Reasons are historical, that this module was not developer in yast team, but in Immunix. I really suggest if you want to have more changes, to do it separately in separate pull request, as it is easier to discuss it separatelly and also it avoid situation that it need big change somewhere, which require rewrite of all your changes. > > > > > > >> + if status != @service_enabled > >> + Yast::Report.Error(_('Failed to change apparmor service. Please use journal (journalctl -n -u apparmor) to diagnose')) > >> + else > >> + # Enable the configuration frame since everything went well > >> + Yast::UI.ChangeWidget(Id(:aaEnableFrame), :Enabled, status) > >> + end > >> end > >> + > >> end > >> end > >> > >> -Yast::ApparmorSettingsClient.new.main > >> +AppArmor::ApparmorSettings.new.run > > > > Btw, recent practive in yast is to have really small client ( like two lines > > ``` > > require "y2apparmor/clients/my_client" > > > > Y2Apparmor::Clients::MyClient.run > > ``` > > > > and having code for client in lib/y2apparmor/clients/my_client.rb. > > This will allow much easier unit testing of code in client ( as require do not run code automatic ) > > Yes, I noticed that in the yast-journalctl tutorial. The way I divided > it is to keep all yast-apparmor interactions in lib/ and keep the rest > in clients. Does it have to be in lib/y2apparmor/clients or just lib/ > would do as yast-journalctl tutorial mentions? > Well as I said, problem with clients is that it cannot be easy tested. It is fine if you have it in lib/y2apparmor/clients and in src/clients have only thin wrapper that call it. -- 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 14 Jun '17

14 Jun '17

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-add-on: - [WIP] Ask when the added repository is unsigned (bsc#1009127) (126 days) https://github.com/yast/yast-add-on/pull/37 Pending requests in repository yast-bootloader: - Use shared RSpec examples for CWM widgets (85 days) https://github.com/yast/yast-bootloader/pull/414 - don't create grub_installdevice and let perl-Bootloader run grub2-install (70 days) https://github.com/yast/yast-bootloader/pull/413 Pending requests in repository yast-core: - AnyAgent - improved logging to easier find bugs similar to bsc#1030425 (42 days) https://github.com/yast/yast-core/pull/120 Pending requests in repository yast-ldap: - Manipulate system LDAP configuration rather than application LDAP configuration (70 days) https://github.com/yast/yast-ldap/pull/26 Pending requests in repository yast-live-installer: - - Use /etc/products.d/openSUSE.prod as /etc/products.d/baseproduct (4 days) https://github.com/yast/yast-live-installer/pull/15 - - Use /etc/products.d/openSUSE.prod as /etc/products.d/baseproduct (4 days) https://github.com/yast/yast-live-installer/pull/14 Pending requests in repository yast-mail: - [WIP] return back MailTable to yast2-mail module from yast2 module (69 days) https://github.com/yast/yast-mail/pull/25 Pending requests in repository yast-network: - [WIP][Sle15] DNS ay setup written in first stage (4 days) https://github.com/yast/yast-network/pull/520 - routing/firewall: no longer depend on SuSEfirewall2 for IPv4 forwarding (42 days) https://github.com/yast/yast-network/pull/503 Pending requests in repository yast-packager: - [WIP] Ask when the added repository is unsigned (bsc#1009127) (125 days) https://github.com/yast/yast-packager/pull/230 Pending requests in repository yast-security: - [WIP] refactoring autoconverted ruby code into ruby code (62 days) https://github.com/yast/yast-security/pull/40 Pending requests in repository yast-storage: - Propose /boot for encrypted root on PowerPC (69 days) https://github.com/yast/yast-storage/pull/155 Pending requests in repository yast-support: - now SR number can be longer then 11 as we already eat that numbers, s… (7 days) https://github.com/yast/yast-support/pull/12 Pending requests in repository yast-tune: - add docker to sle12sp2 (5 days) https://github.com/yast/yast-tune/pull/23 Pending requests in repository yast-users: - Reduce perl (70 days) https://github.com/yast/yast-users/pull/137 Pending requests in repository yast-vm: - Issue 19 tumbleweed (8 days) https://github.com/yast/yast-vm/pull/20 ERROR: API query limit exceeded -- 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] [PATCH 0/3] yast-apparmor: Remove Perl dependency
by Goldwyn Rodrigues 13 Jun '17

13 Jun '17

Apparmor has come a long way since we wrote yast scripts for apparmor. For one, it has changed most of its utils to use python instead of perl. perl libraries in apparmor are no longer maintained and soon will be removed. In order to get yast up to times with apparmor changes, I propse the following patches. The patches are not up to mark to be included immediately, so I decided to send it here so it gets a better review as opposed to a pull request. Mostly, I think it can be improved in layout. I worked with the apparmor team to include JSON in the tools which is under review and will be included soon. Tools such as aa-logprof and aa-genprof are interactive, like a question-response session and hence need libraries like ruby popen to handle that. The communication is in JSON and is converted to a Yast dialog and the response is converted to a JSON response the tool expects. We will lose the ability to edit a profile (which was not complete currently). The prime reason being we cannot generate a complete list of changes we can have and such things are ever-changing. Besides, we don't want to add the logic of validating keywords in Yast. If there is a demand, we can consider options possible. TODO: In the future, I intend to add generating profiles for new programs. This would ease the process of adding new profiles. -- Goldwyn -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 9

[yast-devel] CWM Widgets: a rant ;-)
by Ancor Gonzalez Sosa 13 Jun '17

13 Jun '17

I just wanted to share something that has been in my head for some time. As programmers, we tend to have some personal affection to "our creatures", so please don't take it too serious. And consider this a very low-priority mail, compared to other recent mails in this list. :-) I have never liked CWM Widgets much and I must say I don't know them in depth. So I will say many non accurate things in this mail and you are free to consider this almost as FUD :-). On the other hand, not being as familiar as the creators can be a good thing - when you get used to the quirks of a technology you don't see them anymore. TLDR; Things that really need to be reusable can be made reusable with a more straightforward and flexible approach. And using a single "reusable" CWM in your dialog actually enforces all your code (including the dialog itself) to play by the CWM rules. I'm not sure if I like that. Although maybe the gain is worth the price and I'm simply failing to see it. Now the long version. I consider the creation of the expert partitioner a great showcase of the things I dislike from CWM. There was already a working prototype in yast-storage-ng (and is still there)[1]. It contains some "debatable" lines of Ruby code and it rates very low in CodeClimate for many reasons. I didn't write it and, is you ask me, I don't even like it much. :-) BUT it uses plain Ruby classes and rely in the nice and straightforward UI::Dialog and its event loop. You can understand how the code works in 2 minutes. And if you open a random file, you will know in which part of the partitioner are you and how the interaction with Y2Storage works (listing, creating or deleting partitions, LVs, etc.) at first sight. In one word - straightforward. Now let's take a look to the CWM-based yast-partitioner[2]. Sure it does more things and has the limitation of being forced to clone the not-so-nice UI of the old partitioner. But even having that into account, the level of complexity there is a little bit daunting. When reading a piece of code, I never know where it fits in the overall picture. Martin already suggested to create some kind of "map" for newcomers with diagrams and links, which is a sign. And all that because: 1) CWM Widgets are way more than widgets They take a lot of responsibility and are in full control of the event loop. They manage user input, route the user between dialogs/widgets, store the result in the domain classes (or YCP modules), trigger the real changes in the system... In a MVC pattern (just as a well known pattern, even if we don't follow it), a single widget will be the whole V the whole C and a even a significant part of the M. 2) CWM is a dictator :-) Maybe as a consequence of the point above, the usage of CWM impose a concrete way of doing things for your YaST client. They need extra workarounds to play together with other modern parts of YaST that embrace OOP. For example, during the development of the partitioner, somebody wanted to create a dialog just using our beloved UI:Dialog class. To make it possible we ended up creating a CWM widget that represents a dialog, so the dialog is contained in the widgets system (and not the other way around) and then it can play by the CWM rules and be used. I also have the impression that the CWM model encourages too much the usage of a Singleton approach in the "models layer". Something that made a lot of sense for YCP modules (that are singleton by definition), but I don't like that much with OOP. But this can, of course, be just a subjective impression. 3) Reusability can be easier than that We already have examples of reusable "widgets" that don't embrace the CWM model in YaST. Like the widget to stop/start/enable/disable services, the recent presenter to show a list of actions in the devicegraph with the ability to collapse/extend some parts or even some parts of the mentioned expert partitioner prototype. They are usually quite simple and straightforward. A initializer to set the initial state or to pass the object(s) they "wrap", a handler for the user input, a method returning the current tree of UI terms... and that's usually it. They are compatible with any possible approach used in the UI, not imposing a given paradigm. They can be used inside a CWM-style dialog, inside a UI:Dialog, directly in a proposal client, etc. because the don't over-do. 4) Relatively complex mechanism even for simple stuff I have mixing feelings about this point. On the one hand, I kind of like the CWM approach of using classes for everything. On the other hand, sometimes it feels overkill for many cases to define a new class and then instantiate a new object for very simple tasks like adding a button. That's specially true for stuff that you don't really want to be reusable, but that you want to fit in the whole picture of classes and subclasses. In general, adding a button or a label is usually not as easy as... well, adding a button or a label. :-) Pheew! Feel much better now. ;) Deactivating rant mode. Cheers. [1] https://github.com/yast/yast-storage-ng/tree/master/src/lib/expert_partitio… [2] https://github.com/yast/yast-partitioner/ (many things are still not merged in master at the time of writing) -- 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

2 2

[yast-devel] Re: Query on btrfs on SLES12
by Stefan Hundhammer 13 Jun '17

13 Jun '17

On 13.06.2017 11:56, Suresh K Hosamani wrote: > For OES, one of the product requires other than brtfs filesystem, but by default SLES12 configures btrfs, is there any way to change the default proposal to ext3 for root (/ partition through yast code or control.xml. Currently we chaning manully in the partitioning screen and going ahead, but this cannot be done on every single server. > > Can somebody help me in changing the default proposal to ext3. I thought we had a parameter for this, but it looks like in the old YaST storage stack (as opposed to the new one we are currently writing) there is nothing in control.xml for that, just the "proposal settings" the user can change interactively. Documentation: https://github.com/yast/yast-installation/blob/master/doc/control-file.md#p… Example (SLES): https://github.com/shundhammer/skelcd-control-SLES/blob/master/control/cont… You can change many things on that level, but AFAICS the root filesystem type is not among them (unless I overlooked something). Since your target product is OES which is based on SLES, I guess waiting for storage-NG, the next-generation storage stack (approaching with the next SLE major release), is out of the question for you, right? 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

1 0

[yast-devel] Query on btrfs on SLES12
by Suresh K Hosamani 13 Jun '17

13 Jun '17

Hi, For OES, one of the product requires other than brtfs filesystem, but by default SLES12 configures btrfs, is there any way to change the default proposal to ext3 for root (/ partition through yast code or control.xml. Currently we chaning manully in the partitioning screen and going ahead, but this cannot be done on every single server. Can somebody help me in chaning the default proposal to ext3. Regards, Suresh

1 0

[yast-devel] Pending Pull Requests
by yast-ci＠opensuse.org 13 Jun '17

13 Jun '17

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-add-on: - [WIP] Ask when the added repository is unsigned (bsc#1009127) (125 days) https://github.com/yast/yast-add-on/pull/37 Pending requests in repository yast-bootloader: - Use shared RSpec examples for CWM widgets (84 days) https://github.com/yast/yast-bootloader/pull/414 - don't create grub_installdevice and let perl-Bootloader run grub2-install (69 days) https://github.com/yast/yast-bootloader/pull/413 Pending requests in repository yast-core: - AnyAgent - improved logging to easier find bugs similar to bsc#1030425 (41 days) https://github.com/yast/yast-core/pull/120 Pending requests in repository yast-ldap: - Manipulate system LDAP configuration rather than application LDAP configuration (69 days) https://github.com/yast/yast-ldap/pull/26 Pending requests in repository yast-mail: - [WIP] return back MailTable to yast2-mail module from yast2 module (68 days) https://github.com/yast/yast-mail/pull/25 Pending requests in repository yast-network: - routing/firewall: no longer depend on SuSEfirewall2 for IPv4 forwarding (41 days) https://github.com/yast/yast-network/pull/503 Pending requests in repository yast-packager: - [WIP] Ask when the added repository is unsigned (bsc#1009127) (124 days) https://github.com/yast/yast-packager/pull/230 Pending requests in repository yast-security: - [WIP] refactoring autoconverted ruby code into ruby code (61 days) https://github.com/yast/yast-security/pull/40 Pending requests in repository yast-storage: - Propose /boot for encrypted root on PowerPC (68 days) https://github.com/yast/yast-storage/pull/155 Pending requests in repository yast-support: - now SR number can be longer then 11 as we already eat that numbers, s… (6 days) https://github.com/yast/yast-support/pull/12 Pending requests in repository yast-theme: - Removes "N" from logos to fix bug #953761 (33 days) https://github.com/yast/yast-theme/pull/77 Pending requests in repository yast-users: - Reduce perl (69 days) https://github.com/yast/yast-users/pull/137 Pending requests in repository yast-vm: - Issue 19 tumbleweed (7 days) https://github.com/yast/yast-vm/pull/20 ERROR: API query limit exceeded -- 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 FATE entries in openSUSE
by Tomas Chvatal 12 Jun '17

12 Jun '17

Hello all, board discussed the state of FATE entries we have in openSUSE and decided to cleanup the slate to keep only those that are reasonable and doable within decent time frame. As such I am closing bunch of entries and while doing so I noticed loads of FATE entries on Yast. Could you guys please check the following list and shortly evaluate them? Something along lines of "good idea - doable, ok but resource hog, completely crazy,..." (also for the last ones even feel free to close them right away :P). 307255 Less scary yast conflict dialogs 302047 Integrated package searching for YaST and build service 312191 Driver management YaST module 310151 YAST Software Manager-Search also in openSUSE Build Service 322297 Yast2 working in wayland 311288 Add YAST feature to remove application settings 310913 Add YAST module to set up multiseat installations 307746 Yast2-UI to mount remote Samba/Windows/CIFS-shares 306315 Improve PK/zypper/YaST Big Lock 314975 Enhanced YaST--> Boot Loader Tool 314624 Re-implement the Section Management tab in YAST - Boot Loader for grub2 308765 Provide import/export of repositories list from YaST 318356 Add firewalld and YaST support to openSUSE 309296 YaST2-software manager : Add "Action after Installation" option 317856 UEFI bootloader support in YaST-bootloader 311338 YaST debconf Module 316842 grub2 configuration in Yast2 312690 YaST Software Management -- Install from cache 310609 Yast2 log search 309838 Add a set of favourite modules in YaST control centre 322073 yast should not override ip_forward setting 321731 Yast2: add run on battery option for cron-update 322055 Safe installation mode 319717 yast-btrfs-maintainance module (conception) 320873 [R] Remove copy_to_system from control.xml and AutoYaST 318771 Unified UI for modules managing services TIA Tom

1 0

[yast-devel] Pending Pull Requests
by yast-ci＠opensuse.org 12 Jun '17

12 Jun '17

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-add-on: - [WIP] Ask when the added repository is unsigned (bsc#1009127) (124 days) https://github.com/yast/yast-add-on/pull/37 Pending requests in repository yast-bootloader: - Use shared RSpec examples for CWM widgets (83 days) https://github.com/yast/yast-bootloader/pull/414 - don't create grub_installdevice and let perl-Bootloader run grub2-install (68 days) https://github.com/yast/yast-bootloader/pull/413 Pending requests in repository yast-core: - AnyAgent - improved logging to easier find bugs similar to bsc#1030425 (40 days) https://github.com/yast/yast-core/pull/120 Pending requests in repository yast-ldap: - Manipulate system LDAP configuration rather than application LDAP configuration (68 days) https://github.com/yast/yast-ldap/pull/26 Pending requests in repository yast-mail: - [WIP] return back MailTable to yast2-mail module from yast2 module (67 days) https://github.com/yast/yast-mail/pull/25 Pending requests in repository yast-network: - routing/firewall: no longer depend on SuSEfirewall2 for IPv4 forwarding (40 days) https://github.com/yast/yast-network/pull/503 Pending requests in repository yast-packager: - [WIP] Ask when the added repository is unsigned (bsc#1009127) (123 days) https://github.com/yast/yast-packager/pull/230 Pending requests in repository yast-pkg-bindings: - Merge sle 12 sp2 into master (9 days) https://github.com/yast/yast-pkg-bindings/pull/74 Pending requests in repository yast-security: - [WIP] refactoring autoconverted ruby code into ruby code (60 days) https://github.com/yast/yast-security/pull/40 Pending requests in repository yast-storage: - Propose /boot for encrypted root on PowerPC (67 days) https://github.com/yast/yast-storage/pull/155 Pending requests in repository yast-theme: - Removes "N" from logos to fix bug #953761 (32 days) https://github.com/yast/yast-theme/pull/77 Pending requests in repository yast-users: - Reduce perl (68 days) https://github.com/yast/yast-users/pull/137 Pending requests in repository yast-vm: - Issue 19 tumbleweed (6 days) https://github.com/yast/yast-vm/pull/20 ERROR: API query limit exceeded -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0