February 2020 - YaST Development - openSUSE Mailing Lists

[yast-devel] Hack Week report: learn Crystal by porting part of YaST to that language
by Ancor Gonzalez Sosa 13 Feb '20

13 Feb '20

During this Hack Week I wanted to experiment with Crystal doing something concrete. See more details at [1] and [2]. Josef Reidinger joined the project as well. So first, the TLDR; 1) We migrated quite some non-trivial code from Ruby to Crystal. Porting Ruby+RSpec code to Crystal+Spectator was surprisingly smooth. 2) No, we don't have benchmarks to show the memory consumption or speed improvement of the migrated code. 3) Then we tried to create Crystal bindings for libstorage-ng (a library written in C++). The experience was not that good, we failed. 4) I have been asked, so you plan to port YaST to Crystal? The answer is no. Crystal is a great language but the ecosystem is far from the level of maturity needed for a multi-platform LTSS system. Now the long version... For those who don't know what Crystal is. It's a statically type-checked programming language that compiles into very efficient native code, while looking very similar to Ruby. It has a VERY similar syntax (although compatibility with it is not a goal) and a very similar approach to object oriented programming (at least, in the part of it everyone uses in a daily basis). So back to (1). Porting code from Ruby to Crystal is often as simple as: mv class.rb class.cr Yes, really. It's surprisingly easy. Although Crystal is statically type-checked, the compiler does a great job in inferring the types for everything. That, together with union types and null reference checks, makes everything really smooth. But we wanted to challenge the language, so the code we ported included many things I expected to be tricky to migrate, like defining operators, using metaprogramming to add new class methods to the native numeric classes, using Ruby's "const_get" to decide during runtime which exact class to instantiate, using Ruby's "send" with a variable number of arguments, defining and using mixins, holding references to objects that could be of several classes with no common ancestor... Some of those things just worked as-is in Crystal. With no change needed. All the others were easy to implement using macros. Macros are Crystal's answer to metaprogramming and they are a really powerful tool. The approach is very different to Ruby metaprogramming, so this is the part where a simple rename of the file or even some semi-advanced automatic conversion wouldn't be enough to migrate. But macros definitely look powerful enough to solve most of the things we currently solve with metaprogramming in Ruby. Another nice surprise. But we also wanted to port the RSpec testsuite. A testsuite that makes good use of contexts, "let", mocking and stubbing. That is, things like this: describe Y2Storage::AutoinstIssues::List do subject(:list) { described_class.new } let(:section) { Y2Storage::AutoinstProfile::SkipListSection.new } let(:issue) { instance_double(Y2Storage::AutoinstIssues::Exception) } describe "#add" do it "adds a new issue to the list" do list.add(:exception, StandardError.new) expect(list.to_a) .to all(be_an(Y2Storage::AutoinstIssues::Exception)) end it "passes extra arguments to issue instance constructor" do expect(Y2Storage::AutoinstIssues::InvalidValue) .to receive(:new).with(section, :size, "value") list.add(:invalid_value, section, :size, "value") end end end Thanks to Spectator, this turned to also be almost a matter of renaming the file. See the Crystal equivalent: Spectator.describe Y2Storage::AutoinstIssues::List do subject(:list) { described_class.new } let(:section) { Y2Storage::AutoinstProfile::SkipListSection.new } mock Y2Storage::AutoinstIssues::InvalidValue do stub self.new(*args) end describe "#add" do it "adds a new issue to the list" do list.add(:exception, NilAssertionError.new) expect(list.to_a) .to all(be_an(Y2Storage::AutoinstIssues::Exception)) end it "passes extra arguments to issue instance constructor" do expect(Y2Storage::AutoinstIssues::InvalidValue) .to receive(:new).with(section, :size, "value") list.add(:invalid_value, section, :size, "value") end end end Almost identical, isn't it? In short, the experience in migrating code and tests could hardly be better. Now let's skip the second point and jump to (3) - creating bindings for libstorage-ng. The experience there was not that good. We only found one usable generator of C++ bindings for Crystal[3]. It's being currently used to create Qt5 bindings, but is the typical project that relies on a single person which has a single use-case (the mentioned Qt5 bindings). It almost works for the general case, so it could really be a perfect tool with some investment from other sources other than his current only developer. But is still not there. And no, Swig[4] does not support Crystal as output language. Looking at the Crystal code generated by bindgen and at the Ruby code generated by Swig, implementing Swig support for Crystal would be doable, but I don't think there is anyone even trying right now. Which leads us directly to (4). After a week of playing with Crystal I clearly see it is a perfect language to migrate away from the Ruby runtime. The language retains many of the nice things we love from Ruby and it adds some extra goodies. And porting Ruby code to it is a pleasure. If the YaST Team managed to migrate from YCP to Ruby, doing it from Ruby to Crystal would be 20 times easier. But YaST is not a simple project that has to run in a limited set of servers. We must be able to ship a product that can be executed in x86, PowerPC, s390, ARM and whatnot. And we need to be sure the tool used to generate C++ bindings is properly maintained for the following X years. We also need to feel that in the future we will be able to find a library for whatever task (parsing a new file format, for example). In short, we need solid ground to be able to provide LTSS support for something written in Crystal. All that will not happen without a sustained investment in the language itself. Since I don't see SUSE hiring two people to work full-time in Crystal and its ecosystem for the following couple of years, I wouldn't advise any project that needs to be shipped in SLE to migrate from Ruby to Crystal. But for smaller projects that only need to run in a controlled environment... give it a try! EOREPORT [1] https://hackweek.suse.com/projects/learn-crystal-by-porting-part-of-yast-to… [2] https://github.com/ancorgs/y3storage [3] https://github.com/Papierkorb/bindgen [4] http://www.swig.org/ -- Ancor González Sosa YaST Team at SUSE Software Solutions -- 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] YaST logs permissions
by David Díaz 10 Feb '20

10 Feb '20

Hi! Recently, we have been asked to change the save_y2logs generated file permissions[1] because it's only readable by root, which causes troubles[2] when trying to upload it elsewhere as a common user. However, this is not possible because generated logs contain sensitive information like configuration of services, the content of the journal, or firewall configuration. Adding a short explanation in the command output about the need to adjust the permissions when you are going to upload the file could help the user to understand what's going on, but seems to not be enough. The user should also be aware that logs might contain sensitive data and keep them safe. How do you think we could improve that situation? Regards. [1] https://github.com/yast/yast-yast2/issues/978 [2] https://en.opensuse.org/openSUSE:Report_a_YaST_bug#Firefox_fails_to_attach_… -- David Díaz González YaST Team at SUSE Linux GmbH

5 8

[yast-devel] Pending Pull Requests
by yast-ci＠opensuse.org 10 Feb '20

10 Feb '20

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-apparmor: - Port to rake (240 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests in repository yast-bootloader: - Fix resume with uuid partition (207 days) https://github.com/yast/yast-bootloader/pull/564 Pending requests in repository yast-country: - Port to rake (207 days) https://github.com/yast/yast-country/pull/217 Pending requests in repository yast-devtools: - Supplement changes from YCC (12 days) https://github.com/yast/yast-devtools/pull/148 - Move desktop files (245 days) https://github.com/yast/yast-devtools/pull/143 Pending requests in repository yast-installation: - Demo: eager mode of zombie-killer 0.5 (458 days) https://github.com/yast/yast-installation/pull/761 Pending requests in repository yast-network: - network-ng: test cases document (draft) (80 days) https://github.com/yast/yast-network/pull/947 - add initial test cases document (206 days) https://github.com/yast/yast-network/pull/853 Pending requests in repository yast-packager: - Include some hints in the "Priority" label (bsc#1154693) (107 days) https://github.com/yast/yast-packager/pull/482 Pending requests in repository yast-pkg-bindings: - Remove legacy zypp::target::rpm::ConvertDBReport (61 days) https://github.com/yast/yast-pkg-bindings/pull/119 Pending requests in repository yast-python-bindings: - Make python2 binding optional due to its removal (31 days) https://github.com/yast/yast-python-bindings/pull/31 Pending requests in repository yast-squid: - packaging: remove SuSEfirewall2 artifacts (198 days) https://github.com/yast/yast-squid/pull/30 Pending requests in repository yast-sudo: - WIP: Add a CFA model for handling the sudoers file (41 days) https://github.com/yast/yast-sudo/pull/12 Pending requests in repository yast-users: - Move back the UMASK default value to /etc/login.defs (bsc#1099153) (585 days) https://github.com/yast/yast-users/pull/161 Pending requests in repository yast-yast2: - Change the way groups are defined (244 days) https://github.com/yast/yast-yast2/pull/936 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (375 days) https://github.com/yast/yast-yast2/pull/894 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (375 days) https://github.com/yast/yast-yast2/pull/893 - [WIP] Firewalld fixes for the new UI (523 days) https://github.com/yast/yast-yast2/pull/813 - [WIP] Drop SuSEfirewall2 completely (508 days) https://github.com/yast/yast-yast2/pull/806 Pending requests in repository yast-ycp-ui-bindings: - [WIP] Support bold font inside tables (535 days) https://github.com/yast/yast-ycp-ui-bindings/pull/35 Pending requests in repository yast-ruby-bindings: - [WIP] Don't crash on NoMethodError when Perl is involved (38 days) https://github.com/yast/yast-ruby-bindings/pull/224 - log method name (622 days) https://github.com/yast/yast-ruby-bindings/pull/216 Pending requests in repository yast-samba-client: - Use kerberos authentication by default during join (88 days) https://github.com/yast/yast-samba-client/pull/79 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: highlights of development sprint 93
by Imobach González Sosa 07 Feb '20

07 Feb '20

Hi all, Lately, the YaST team has been quite busy fixing bugs and finishing some features for the upcoming (open)SUSE releases. Although we did quite some things, in this report we will have a closer look at just a few topics: - A feature to search for packages across all SLE modules has arrived to YaST. - Improved support for S390 systems in the network module. - YaST command-line interface now returns a proper exit-code. - Added progress feedback to the Expert Partitioner. - Partial support for Bitlocker and, as a lesson learned from that, a new warning about resizing empty partitions. You can find the whole report at https://lizards.opensuse.org/2020/02/07/yast-sprint-93/ Enjoy the Hack Week! -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/

1 0

[yast-devel] YaST at the openSUSE Summit Dublin
by Ancor Gonzalez Sosa 07 Feb '20

07 Feb '20

Douglas DeMaio asked if me or any other YaST developer was planning to give a talk at openSUSE Summit Dublin[1]. I have to admit that was out of my radar. That summit is a small event that takes place right after SUSECON[2] in the same location, reusing part of its infrastructure. So it sounds like a nice place to meet people who are both openSUSE enthusiasts and SUSE customers. To be honest, YaST had almost not presence In the latest openSUSE Conference and that felt pretty wrong. Imo and me tried to fix that with some lighting talks but, although they were well received locally, there is no online record of those. I'm not sure whether I will be personally able to attend, but I think that at least one member of the YaST Team should be there presenting all the new stuff that debuted in 15.1 (we can extend my lighting talk about it) or what we are working on. Being visible is one of our strategies, after all. Cheers. [1] https://events.opensuse.org/conferences/Dublin [2] https://www.susecon.com/ -- 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 4

[yast-devel] Fwd: openSUSE - Google Summer of Code 2020
by Ancor Gonzalez Sosa 05 Feb '20

05 Feb '20

openSUSE is considering to apply for Google Summer of Code this year. We offered some projects in the past, some of them were indeed executed([1],[2]). [1] Alternatives YaST Module https://github.com/openSUSE/mentoring/issues/13 [2] Rewrite Keyboard Management - Done out of GSoC https://github.com/openSUSE/mentoring/issues/79 Others never made it to GSoC for several reasons, although some of them were finally implemented by the YaST Team itself ([3],[4],[5]) [3] REST API for testing based on libYUI https://github.com/openSUSE/mentoring/issues/87 [4] Apache initial setup YaST Module https://github.com/openSUSE/mentoring/issues/12 [5] Native Ruby interface for libYUI https://github.com/openSUSE/mentoring/issues/11 Time to resurrect any of those projects or come with a new one? Anyone willing to mentor? I am, although I have not decided the project yet. Cheers. PS.- It doesn't have to be exactly about YaST, we have had projects in the past about Jangouts, One-click installer, the Travel Support Program application.... https://github.com/openSUSE/mentoring/issues/63 https://github.com/openSUSE/mentoring/issues/78 https://github.com/openSUSE/mentoring/issues/80 https://github.com/openSUSE/mentoring/issues/82 https://github.com/openSUSE/mentoring/issues/16 https://github.com/openSUSE/mentoring/issues/77 https://github.com/openSUSE/mentoring/issues/15 -------- Forwarded Message -------- Subject: [Research] openSUSE - Google Summer of Code 2020 Date: Mon, 27 Jan 2020 10:00:18 +0100 From: ddemaio To: ----- Hi All, Applications for the Google Summer of Code are open and openSUSE members are considering applying for this year's GSoC to be a mentor organization. You would need to be committed to providing a mentor and the mentors would need to write progress reports; I believe there are 2 reports the mentors must write (mid-term review and final review) in addition to the mentoring of the student. The application deadline is Feb. 5, so if you want to do this, please update the git repository (https://github.com/openSUSE/mentoring) for https://101.opensuse.org and I can submit the application. If you have a project that you would like to consider as a GSoC project, please let me know. v/r Doug -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 10

[yast-devel] Inconsistent behavior of YaST Modules when closing without changes
by Ancor Gonzalez Sosa 03 Feb '20

03 Feb '20

This started as a discussion in https://bugzilla.suse.com/show_bug.cgi?id=1161460 which leads me to realize we have the same "hack" repeated in dozens of YaST modules. The point is that there is a function called `Popup::ReallyAbort` that all YaST modules call when asked to quit. The only argument of that function is a boolean saying whether something has changed. If nothing has changed, the function displays a "Really abort?" pop-up. But if some change has been made (i.e. the argument is true), it will add "All changes will be lost!" So we have a common API used by all modules to show a consistent behavior. So far, so good... Or not? Of course, not. This was surely conceived to be used like this: Popup.ReallyAbort(TheModule.modified?) But in practice most modules (all except 4 or 5, as far as I can say) use that function like this: def ReallyAbort !TheModule.modified? || Popup.ReallyAbort(true) end Which actually invalidates the logic of the function and simply shows nothing when quiting without changes. And that very same code is repeated over and over in a dozen of YaST modules. See [1]. Did we at some point decided that quiting without changes should not ask for confirmation? If so, why did we implement the very same bypass for the `Popup.ReallyAbort` logic in dozens of modules instead of changing the behavior of the function (or providing an alternative function)? We should agreed on which is the desired behavior and then implement it by using whatever common function (ReallyAbort or a new one) in an honest way. I created a card for that[2] but I wanted to start the discussion here first. Cheers [1] https://github.com/search?q=org%3Ayast+reallyabort&type=Code [2] https://trello.com/c/UlVLiDTU/ -- Ancor González Sosa YaST Team at SUSE Software Solutions -- 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] Pending Pull Requests
by yast-ci＠opensuse.org 03 Feb '20

03 Feb '20

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-apparmor: - Port to rake (233 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests in repository yast-bootloader: - Fix resume with uuid partition (200 days) https://github.com/yast/yast-bootloader/pull/564 Pending requests in repository yast-country: - Port to rake (200 days) https://github.com/yast/yast-country/pull/217 Pending requests in repository yast-devtools: - Move desktop files (238 days) https://github.com/yast/yast-devtools/pull/143 Pending requests in repository yast-installation: - Demo: eager mode of zombie-killer 0.5 (451 days) https://github.com/yast/yast-installation/pull/761 Pending requests in repository yast-network: - network-ng: test cases document (draft) (73 days) https://github.com/yast/yast-network/pull/947 - add initial test cases document (199 days) https://github.com/yast/yast-network/pull/853 Pending requests in repository yast-online-update-configuration: - Prompt for root password. (292 days) https://github.com/yast/yast-online-update-configuration/pull/21 Pending requests in repository yast-packager: - Include some hints in the "Priority" label (bsc#1154693) (100 days) https://github.com/yast/yast-packager/pull/482 Pending requests in repository yast-pkg-bindings: - Remove legacy zypp::target::rpm::ConvertDBReport (54 days) https://github.com/yast/yast-pkg-bindings/pull/119 Pending requests in repository yast-python-bindings: - Make python2 binding optional due to its removal (24 days) https://github.com/yast/yast-python-bindings/pull/31 Pending requests in repository yast-squid: - packaging: remove SuSEfirewall2 artifacts (191 days) https://github.com/yast/yast-squid/pull/30 Pending requests in repository yast-sudo: - WIP: Add a CFA model for handling the sudoers file (34 days) https://github.com/yast/yast-sudo/pull/12 Pending requests in repository yast-users: - Move back the UMASK default value to /etc/login.defs (bsc#1099153) (578 days) https://github.com/yast/yast-users/pull/161 Pending requests in repository yast-yast2: - Change the way groups are defined (237 days) https://github.com/yast/yast-yast2/pull/936 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (368 days) https://github.com/yast/yast-yast2/pull/894 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (368 days) https://github.com/yast/yast-yast2/pull/893 - [WIP] Firewalld fixes for the new UI (516 days) https://github.com/yast/yast-yast2/pull/813 - [WIP] Drop SuSEfirewall2 completely (501 days) https://github.com/yast/yast-yast2/pull/806 Pending requests in repository yast-ycp-ui-bindings: - [WIP] Support bold font inside tables (528 days) https://github.com/yast/yast-ycp-ui-bindings/pull/35 Pending requests in repository yast-ruby-bindings: - [WIP] Don't crash on NoMethodError when Perl is involved (31 days) https://github.com/yast/yast-ruby-bindings/pull/224 - log method name (615 days) https://github.com/yast/yast-ruby-bindings/pull/216 Pending requests in repository yast-samba-client: - Use kerberos authentication by default during join (81 days) https://github.com/yast/yast-samba-client/pull/79 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