July 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] Innovation time: A repository with AutoYaST XML profiles (PoC )
by Ladislav Slezak 03 May '21

03 May '21

Hi all! I'm implementing some new AutoYaST feature and I found out that it's not easy to test the AutoYaST functionality. 1. Even for testing a trivial scenario you have to write your own XML file. If you do not have much experience with AutoYaST you have to read the documentation, search the internet, etc... Cloning your current system helps a bit but usually the cloned profile contains too many options so you still need to polish it a bit... 2. When you have your profile ready you have to host it at some HTTP/FTP/NFS/... server so AutoYaST can use it for installation. I usually run simple "ruby -run -ehttpd" command to have a web server quickly, but that's quite tricky for people not familiar with Ruby. My idea is to have some repository with example XML profiles which would be publicly available and ready for instant use. We already have some XML files in the autoyast-profiles-test Git repository but writing something like autoyast=https://raw.githubusercontent.com/yast/autoyast-profiles-test/mast… on boot command line is a real pain. We could use some URL shortening service but I do not like that much. Shortened URLs do not look nice and it's not obvious where they point to (security). I'd like to have some nice URLs... So my proposal is to use the GitHub pages for building an AutoYaST profile repository. Then you could use autoyast=https://autoyast.github.io/mini/sles15.xml or autoyast=https://autoyast.github.io/mini/leap15.xml for testing a minimal SLES/Leap profile. Actually these URLs already work! :-) You can give it a try. Most likely you will need additional "netsetup=dhcp" boot option for configuring network. The profiles would be well described (what they do) and well commented (so the users can easily adapt them to their needs). The profiles could be automatically validated (via Travis) and it would be nice to use them also in openQA tests to be sure they really work. We could also link this repository from the official SUSE documentation. The proof of concept is available at https://autoyast.github.io, please check it. It is still just a concept for getting early feedback, there is a lot of work to do. See the README file in https://github.com/autoyast/autoyast.github.io What do you think about it? -- 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] First meeting to discuss the long term vision for our UI framework
by Ancor Gonzalez Sosa 11 Aug '20

11 Aug '20

The YaST team wants to take some time to think in the long term and try to envision the future of our UI design/programming... which may be anything from just an improved libYUI to something completely different and unrelated. It likely makes sense to start discussing what are the requisites (and/or use cases) for the UI of YaST in the long term, so we have planned a meeting with all the interested people in this topic tomorrow Thursday at 2pm CEST. Usual meeting point: https://li2023-182.members.linode.com/#/rooms/2001 As said, the topic will be: requirements for the future UI of YaST. Some food for thought about the topic: - Do we ALWAYS need to offer TUI+GUI for all modules and steps? - Does it have any value to offer something else beyond TUI/GUI? - What are the requisites regarding support for programming languages? Those are not the only points to discuss, just some hints to get your brain started. Cheers. -- 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

6 10

[yast-devel] Innovation Time: Wild(?) UI Ideas
by josef Reidinger 10 Aug '20

10 Aug '20

Hi dear YaSTies, after thursday UI meeting I spend part of today researching and thinking about our UI and do some brainstorming. 1. TUI use cases Beside known limited serial line and low memory systems, one another well known use case is WSL. We use TUI here for firstboot and on windows there is by default no X server. I think that WUI could really help here. What can be a bit like competition to us just on different level is IPMI and it is nowadays provided by BIOS or by WUI see https://www.thomas-krenn.com/en/wiki/Supermicro_IPMI_Configuration_through_… And BIOS uses TUI. 2. terminal output of autoyast Well, to this idea brings me mentioning of readline and also usage of autoyast for more complex cases. Basically idea is to have just progress output for autoyast + error reporting ( so no semi automatic or stuff like this in autoyast ). And instead of TUI beside gui it can use simple terminal output e.g. using this quite nice library - https://github.com/shopify/cli-ui or tty-progressbar 3. WUI for autoyast config When I am thinking about replacing TUI by WUI and how to start, then I think ideal candidate is autoyast config UI because: a. current state is bad b. it is too much restricted by system where it runs ( e.g. just think about how much UI is affected by system architecture like not showing s390 options or not able to run it at all ) c. its output is just XML file, no system modification d. I have in mind nice use case of hosted autoyast config creator with maybe nice feature of using mksusecd and creating dvd including autoyast profile, that can be auto detected. So you download iso with your preconfigured autoyast profile. e. it is not used in installation 4. drag and drop in ncurses it should be possible as mouse support mouse down and also mouse up. See doc at https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/mouse.html BTW there is also quite nice quick intro to curses at https://www.2n.pl/blog/basics-of-curses-library-in-ruby-make-awesome-termin… Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

5 4

[yast-devel] Presentation in openSUSE Conference 2020
by Ancor Gonzalez Sosa 31 Jul '20

31 Jul '20

As mentioned several times in IRC or daily calls, I think the YaST team should have some representation in the "openSUSE + LibreOffice Virtual Conference" taking place on October 15 - 17, 2020. So I submitted the 30min. talk you can see below. If you have more ideas for YaST-related content, please hurry up since the call for papers ends on August 4th. Cheers Title: Top 25 New Features in (Auto)YaST Subtitle: What's new in YaSTland? Abstract: YaST is the most powerful Linux installer. YaST is also a super-comprehensive configuration tool. AutoYaST is an awesome unattended installation system. But with so many features and possibilities, it's sometimes hard to keep track of all the new additions to the YaST toolbox. This presentation will take you through a curated list of the most relevant 25 features that has been introduced in YaST for recent releases of openSUSE Leap and SUSE Linux Enterprise, as well as some features that has only landed in openSUSE Tumbleweed for the time being. -- 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

1 0

Fwd: Re: [apparmor] [yast-devel] Upcoming changes in AppArmor aa-status output
by Christian Boltz 30 Jul '20

30 Jul '20

Hello, I just noticed that this mail about the aa-status changes never made it to yast-devel, probably because John isn't subscribed there. Is this mail with the json examples "good enough", or do you want/need a bugreport to track this? FYI: AppArmor 3.0 will be released soon[tm], so please don't wait too long with adjusting the YaST side. ---------- Weitergeleitete Nachricht ---------- Betreff: Re: [apparmor] [yast-devel] Upcoming changes in AppArmor aa-status output Datum: Mittwoch, 10. Juni 2020, 16:40:50 CEST Von: John Johansen <john.johansen(a)canonical.com> An: Stefan Hundhammer <shundhammer(a)suse.de>, Christian Boltz <opensuse(a)cboltz.de> Kopie: apparmor(a)lists.ubuntu.com, yast-devel(a)opensuse.org On 5/4/20 1:08 AM, Stefan Hundhammer wrote: > On 2020-04-30 13:22, Christian Boltz wrote: >> Hello, >> >> AFAIK the YaST AppArmor module uses the JSON output of aa-status. >> >> There are two upcoming changes, and I'd like to point them out so that >> you can adjust the YaST AppArmor module if needed. > > This time PLEASE remember to also bump the JSON version number of > that output. We had to do a pretty ugly hot fix for that last time, > and it was just coincidence that this did not conflict with the > previous version. > the JSON version was bumped to 2 attached is an example output of aa-status, along with the corresponding pretty json and compressed json output using the new unconfined, kill, mixed, and prompt modes ------------------------------------------------------------- Regards, Christian Boltz -- ein Auto "funktioniert" auch mit eckigen Reifen, ob ich so etwas fahren möchte ist wieder eine andere Frage. [Björn Meier in postfixbuch-users]

2 2

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

27 Jul '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 (408 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests in repository yast-autoinstallation: - Find the Base Product (83 days) https://github.com/yast/yast-autoinstallation/pull/599 Pending requests in repository yast-bootloader: - Add UPDATE_NVRAM in /etc/sysconfig/bootloader (bsc#1157550). (13 days) https://github.com/yast/yast-bootloader/pull/611 - Fix resume with uuid partition (375 days) https://github.com/yast/yast-bootloader/pull/564 Pending requests in repository yast-core: - Fixes for gensalt handling with libxcrypt. (150 days) https://github.com/yast/yast-core/pull/144 Pending requests in repository yast-devtools: - Y2logs analyzer (152 days) https://github.com/yast/yast-devtools/pull/149 - Supplement changes from YCC (180 days) https://github.com/yast/yast-devtools/pull/148 - Move desktop files (413 days) https://github.com/yast/yast-devtools/pull/143 Pending requests in repository yast-installation: - clarify that ssh_import processes host keys (bsc#1172400) (52 days) https://github.com/yast/yast-installation/pull/860 - Demo: eager mode of zombie-killer 0.5 (626 days) https://github.com/yast/yast-installation/pull/761 Pending requests in repository yast-network: - network-ng: test cases document (draft) (248 days) https://github.com/yast/yast-network/pull/947 - add initial test cases document (374 days) https://github.com/yast/yast-network/pull/853 Pending requests in repository yast-packager: - Include some hints in the "Priority" label (bsc#1154693) (117 days) https://github.com/yast/yast-packager/pull/482 Pending requests in repository yast-registration: - [SP3] Fix misleading default_skipping_text (BSC#1167795) (30 days) https://github.com/yast/yast-registration/pull/488 Pending requests in repository yast-users: - Remove ag_uid to save memory at installation time (bsc#1172139) (33 days) https://github.com/yast/yast-users/pull/231 Pending requests in repository yast-yast2: - Bnc#1081441 (102 days) https://github.com/yast/yast-yast2/pull/1047 - [WIP] CWM improvements (103 days) https://github.com/yast/yast-yast2/pull/1044 - Change the way groups are defined (412 days) https://github.com/yast/yast-yast2/pull/936 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (543 days) https://github.com/yast/yast-yast2/pull/894 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (543 days) https://github.com/yast/yast-yast2/pull/893 - [WIP] Firewalld fixes for the new UI (691 days) https://github.com/yast/yast-yast2/pull/813 - [WIP] Drop SuSEfirewall2 completely (676 days) https://github.com/yast/yast-yast2/pull/806 Pending requests in repository yast-ycp-ui-bindings: - WIP: New Widget: MenuBar (UI Interpreter Part) (10 days) https://github.com/yast/yast-ycp-ui-bindings/pull/53 - [WIP] Support bold font inside tables (703 days) https://github.com/yast/yast-ycp-ui-bindings/pull/35 Pending requests in repository yast-ruby-bindings: - Fixes for gensalt handling with libxcrypt. (150 days) https://github.com/yast/yast-ruby-bindings/pull/239 - [WIP] Don't crash on NoMethodError when Perl is involved (206 days) https://github.com/yast/yast-ruby-bindings/pull/224 - log method name (790 days) https://github.com/yast/yast-ruby-bindings/pull/216 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] Documentation about .d files/dirs
by Lukas Ocilka 23 Jul '20

23 Jul '20

Hi guys, Thanks to David and Imo. I've found out that there is a documentation about where we are with using/packaging /usr/etc/ and .d files and dirs considering openSUSE: https://en.opensuse.org/openSUSE:Packaging_UsrEtc This page explains the concept, packaging expectations, dark rituals, and also differences between various cases. Spoiler: Contains also list of packages that already use this feature or plan to do so. The list might be incomplete though, e.g., Chrony is missing... HTH Lukas -- Lukas Ocilka, Systems Management Team Leader & YaST Product Owner SLE Department, SUSE Linux 🌲 Please consider the environment before printing this e-mail ☂ Handle with care - Your reply can be stored in the cloud 😱 Pie-chart is just a representation of randomly chosen data ⚠ 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