January 2020 - YaST Development - openSUSE Mailing Lists

[yast-devel] Overcommit - automatic checks via Git hooks
by Ladislav Slezak 21 Dec '22

21 Dec '22

Hi, I found a quite interesting tool called Overcommit [1]. It provides an easy way for setting up Git commit hooks and provides some basic checking plugins. The nice feature of the Git commit hooks is that you can run some checks automatically and early in the development. For example with the commit hooks you can run Rubocop check automatically whenever a commit is created. And if the check fails the commit is not created. I can see "make Rubocop happy" commits quite often (happens to me as well), with Overcommit you can easily avoid that. I have tried several Overcommit checks: - Rubocop - runs Rubocop at "commit" - Rspec - runs the tests before "push" - Branch blacklist - can forbid direct commits to configured branches, e.g. "master" (forces using pull requests, avoids commits to master my mistake) - Commit message spellcheck - warns when there is a possible typo Check my blog post [2] for the details, esp. watch the recorded screencast where I wanted to show some mistakes which it can catch. The tool looks promising, I'll try using it for some time. If you want to try it as well check the blog post for the installation steps. Enjoy! [1] https://github.com/brigade/overcommit [2] http://blog.ladslezak.cz/2016/06/06/overcommit/ -- 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

3 3

[yast-devel] YaST Tips&Tricks
by Ladislav Slezak 25 Jan '22

25 Jan '22

Hi all, some time ago we discussed where and how we should share "Tips&Tricks" for YaST users and developers. IIRC there was no clear conclusion so I decided to start a wiki [1] to collect all our tricks we know or use. For now it's just a place for dumping your ideas, links, short howtos, etc... When we collect enough data we can probably split it to several categories or move it somewhere else. We just need the data first. I have added there some my tricks from my personal "knowledgebase" file. If you have better tricks or find something wrong simply change it, it's a wiki ;-) Ladislav [1] https://github.com/yast/yast.github.io/wiki/YaST-Tips-and-Tricks -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- 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] Reminder: verify_partial_doubles is not default
by Josef Reidinger 03 Dec '20

03 Dec '20

Hi, again I hit by thinking that verify_partial_doubles is now default in rspec3. It is not and will be in rspec4. So what it means? rspec does not check if mocked methods exists at all and it can result in many not so funny errors in test suite. I am just faced it in network, so I create non trivial commit[1] that enables it there. It includes also how to avoid failures on mocked class[2] which avoided build dependencies. From list of errors it can check is typos[3], mocking of wrong class[4] and mocking non-existing methods[5]. So feel free to take it as inspiration and enable it also in your test helper. Josef [1] https://github.com/yast/yast-network/pull/830/commits/e18da64fce25242a51710… [2] https://github.com/yast/yast-network/pull/830/commits/e18da64fce25242a51710… [3] https://github.com/yast/yast-network/pull/830/commits/e18da64fce25242a51710… [4] https://github.com/yast/yast-network/pull/830/commits/e18da64fce25242a51710… [5] https://github.com/yast/yast-network/pull/830/commits/e18da64fce25242a51710… -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 3

[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

Re: [yast-devel] Re: Partitioner: changing the default tab
by Lukas Ocilka 31 Jan '20

31 Jan '20

On 1/24/20 10:57 AM, Ancor Gonzalez Sosa wrote: > First of all, I'm moving this discussion to the yast-devel mailing list. > This is not internal team stuff. > > On 1/23/20 3:36 PM, David Díaz wrote: >> Hi folks! >> >> As part of my current PBI[1], I must raise a discussion about the >> default behavior of pages with tabs in the Partitioner :) >> >> The question is simple, should we really display the "Overview" tab by >> default? During the planning, it seems to some of us that it is useless >> most of the time. Taking a disk with three partitions as an example, we >> think it could be more practical to directly land in the "Partitions" tab. (Re-sending what I wrote elsewhere) I'm still using 15.1 so comments are about that state. My laptop contains two disks by default, I use LVM, no btrfs. - YaST Disk starts at "Available storage on *" and I never found it any useful as it contains everything mixed together - Hard Disks does not list hard disks, but Disks and Partitions, again, not very useful, but better - A particular disk, when selected, lands at Overview and again, I never found it any useful as I'm not interested in any of the info there I'd probably really expect - To see only disks, when I click on Hard Disks - To go directly to partitions when selecting a disk - To see Volumes when selecting a LV instead of seeing overview Obviously all this comes from use-cases. You have a different use-case when installing a machine and different use case when you want to tune your partitioning or get more info about disks/partitions on your running system. Of course, there are more ideas that I'd write here just after seeing the partitioner after a few weeks without using it but this is already enough. Thanks for opening the topic Lukas -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

6 10

Re: [yast-devel] Online Search: module/extension dependencies
by Imobach González Sosa 31 Jan '20

31 Jan '20

On Thu, 2020-01-30 at 17:16 +0000, Kenneth Wimer wrote: > Allowing users to select packages for installation without having > registered the product seems like your creating a situation in which > the installation process itself will become over-complicated and > confusing. I would seriously think about registering the product > before the installation overview. Well, zypper allows to do that (searching without being registered). But it is a different case, as zypper won't let you to register anyway. I am not sure whether it is a hard-requirement (to be on par with zypper). If "just searching" is a use case, I guess we need to support it. Jiri or Lukas, any comment about this? > > I am not sure whether I have clarified something :) > > Yeah, this whole thing is so complex! It’s very hard to understand > what is best for the user vs what would be best for the > developer/system. Yes, you are right. From the developers point of view, we already have done the hardest part :) It is a matter simplifying/adjusting the workflow as much as possible to make things easier to use and maintain. But it is not easy to find the balance. Thanks. Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/

1 0

[yast-devel] Online Search: module/extension dependencies
by Imobach González Sosa 30 Jan '20

30 Jan '20

Hi all, I am extending the online search feature[1] to work on unregistered systems and I have found out that you need to be registered to get the list of available modules/extensions. Basically, when you search for a package, you get this information: { "data": [ { "id": 19795225, "name": "apache2-mod_php7", "arch": "x86_64", "version": "7.3.13", "release": "1.7", "products": [ { "id": 1976, "name": "Web and Scripting Module", "identifier": "sle-module-web-scripting/15.2/x86_64", "type": "module", "free": true, "edition": "15 SP2", "architecture": "x86_64" } ] } ] } However, it does not contain dependencies information (the "Web and Scripting Module" depends on "Server Applications Module"), so we are not able to display an advice[2]. I guess we have these options: 1) Do not display this information when working in an unregistered system. When the user clicks "Next", the base system should be registered and, at that point, we will get that info. Then we could display a "Summary" screen informing the user about the dependencies (before registering the modules/extensions). 2) Use a "Summary" screen for registered and unregistered systems. See the Alternative Workflow[3] description. 3) Ask the SCC team to extend the API offering a list of available module/extensions including its dependencies. After all, they already provide a list of base produts through the API[4]. If you ask me, option 2) should be easy (and quick) to implement but it will change the current workflow. Is it better/worst than the current one? I am not sure (waiting for Ken's feedback). Option 3) might take more time (we will depend on SCC guys) and I would like to omit option 1). Opinions? Thanks! Regards, Imo [1] https://gist.github.com/imobachgs/5651c4833cd8c7365806d3b422fbac51 [2] https://user-images.githubusercontent.com/15836/73285859-95d4e200-41ee-11ea… [3] https://gist.github.com/imobachgs/5651c4833cd8c7365806d3b422fbac51#an-alter… [4] https://scc.suse.com/api/package_search/v4/documentation#/packages/get_prod… -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/

2 2

Re: [yast-devel] Online Search: module/extension dependencies
by Imobach González Sosa 30 Jan '20

30 Jan '20

On Thu, 2020-01-30 at 15:40 +0000, Kenneth Wimer wrote: > From a SLES point of view, if the user has to register the products > necessary to get the additional packages he/she is searching for, > then the base-system definitely needs to be registered. Yes, but you can search for the packages before deciding whether to register the system or not. Moreover, zypper does allow to search without registering the base system, and YaST should be on-par with zypper. > Is there a use-case to allow a user to install SLES, not register it, > and then look for other packages belonging to another product? If > they want to install any packages I assume they have to register all > products first anyway (ie including the base-system). The user can install SLES, not register it, and look for packages in extensions/modules (also known as products in SCC jargon). But are not allow for packages in a different base product. Of course, if he/she is interested in *installing a package*, registration will be required. > Everything else seems like a lot of work for questionable benefit (as > I understand the situation but maybe I'm missing something). In a nutshell, you should be able to search packages (no matter if the base system is registered or not). After you have decided with packages you want to install, you should register the base system (if needed) and the required addons. I am not sure whether I have clarified something :) Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/

1 0

Re: [yast-devel] Re: Partitioner: changing the default tab
by Lukas Ocilka 30 Jan '20

30 Jan '20

On 1/29/20 10:25 AM, Ancor Gonzalez Sosa wrote: >> - YaST Disk starts at "Available storage on *" and I never found it any >> useful as it contains everything mixed together > > BTW, we improved a bit that view in the latest sprint (still not visible > in Tumbleweed) so all devices can be managed directly from there thanks > to the contextual buttons. > See https://github.com/yast/yast-storage-ng/pull/1024 OK, good to have those buttons, but I still see it "a bit" overfilled with content. My "Available storage *" contains 10 items: two disks, LVM. Imagine an overview with RAID, LVM, three disks... >> I'd probably really expect >> >> - To see only disks, when I click on Hard Disks >> - To go directly to partitions when selecting a disk > > Always? Also for hard disks that are formatted directly (without > partition table) or fully empty? Good question if I hadn't written "Obviously all this comes from use-cases." a few lines below :D For my use-case, yes. > Same question applies to software RAIDs, that traditionally were used as > "virtual partitions" (i.e. formatted directly) but since storage-ng can > also be partitioned (so they are seen more like "virtual disks" now). > Would you also expect to land in "partitions" for them? In that regard, > I couldn't say which one of the use-cases (formatting them or > partitioning) is more common or more useful . Maybe the problem is that we call it "Partitions" while we actually show "how the disk is divided into partitions (or not)" ;) We should not stick to old naming especially as we currently allow more than in the past where we were (most probably) just working with partitions. > And same question applies to Bcache devices, that (like disks and > RAIDs), can also be formatted/mounted directly or partitioned. Would > "partitions" also be your expected tab there? I don't have any expectations there as I don't use btrfs myself. >> Obviously all this comes from use-cases. You have a different use-case >> when installing a machine and different use case when you want to tune >> your partitioning or get more info about disks/partitions on your >> running system. >> >> Of course, there are more ideas that I'd write here just after seeing >> the partitioner after a few weeks without using it but this is >> already enough. > > Yes, the whole think needs to be redesigned from the ground. But we > still lack that new "vision" that really rings the bell about how things > should be. I would not dare to say "redesigned", I'd say "rethought". So, what are my expectations? The UI should be... 1. Understandable for the first sight 2. Based on real use-cases (we need to collect them first) 3. Fewer is more (in meaning: better) 4. But not too few (insufficient) 5. We might need Wizards to setup complex things too 6. Using more UI possibilities if that helps (e.g., Device graph) Don't let me think http://www.scottsdevelopers.com/dont-make-me-think-revisited.pdf Anyway, please, don't get me wrong. I believe that the team does a great job making the YaST Disk better and better and especially I do thank Ancor for driving that thing! :) -- Lukas Ocilka, Systems Management Team Leader & YaST Product Owner SLE Department, SUSE Linux 🌍 It's not too late to changee ourselves ⧖ ☂ Handle with care - Your reply can be stored in the cloud 🎃 IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please, notify the sender immediately and do not disclose the contents to anyone or make copies of thereof. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0