YaST Development April 2020

yast-devel@lists.opensuse.org

19 participants
35 discussions

[yast-devel] Reminder: verify_partial_doubles is not default

by Josef Reidinger

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 months, 2 weeks

[yast-devel] Debugging Travis - SSH Access

by Ladislav Slezak

Hi all, Travis now supports debugging builds where it enables SSH access to the running VM: https://docs.travis-ci.com/user/running-build-in-debug-mode Unfortunately, for security reasons this is not available for public repositories. And public forks cannot be simply changed to private ones... :-/ So there is a bit complicated way, you need to create a new empty repository and mirror the content from the target repository there: https://help.github.com/en/github/creating-cloning-and-archiving-repositori… Note: for accessing the private repositories at Travis you need to use the https://travis-ci.com URL, the https://travis-ci.org only displays the public GitHub repositories. When you start a debug build the VM prints the SSH command for accessing it. It does not start the build, you can do that via SSH or you can inspect the environment before running the tests... The session is running for some limited time (maybe 20 minutes? I have not measured that, but it is quite long). After a timeout the job is aborted. If you still need it you can restart the build again, just maybe you will need to repeat some steps again, just be prepared for that. HTH -- 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

10 months, 3 weeks

[yast-devel] Expert Partioner: Leap 15.3 and beyond

by Ancor Gonzalez Sosa

The interface of the YaST Partitioner has reached a point in which is really hard to deal with it. We need to find a way to move forward. As a first step, we have created this document that explains the problem and we hope it can be used as a base to discuss the future of the Partitioner interface. https://github.com/yast/yast-storage-ng/blob/master/doc/partitioner_ui.md This is a very important topic for the future of YaST. All ideas are welcome. Feel free to reply to this mail, to create pull requests for the document, to discuss the topic at #yast channel at Freenode... whatever works for you. 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

10 months, 4 weeks

[yast-devel] Branching SLE-15-SP2 today at 16:00 CEST (14:00 UTC)

by Ladislav Slezak

Hello! Today I'll create the SLE-15-SP2 maintenance branch from master for all YaST and libyui packages. I'll start around 16:00 CEST (14:00 UTC). Because there are so many packages it will take some time, I'll let you know when it's done. So if you still have some pull requests for the SP2 open then merge them ASAP, or change the target branch after the SP2 branch is created. -- 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

11 months

[yast-devel] Upcoming changes in AppArmor aa-status output

by Christian Boltz

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. a) new profile modes Besides complain and enforce mode, future AppArmor versions (>= 3.0) will also have `unconfined`, `mixed` and `kill`. Technically the structure of the JSON doesn't change, but there will be new values for the status, for example "processes": { "/usr/lib/GConf/2/gconfd-2": [ { "pid": "3899", "profile": "/usr/lib/GConf/2/gconfd-2", "status": "kill" } ] } "profiles": { "/does/not/exist": "kill" } Side question: Do you think this warrants increasing the JSON version number? Quick explanation about the new modes: - unconfined: similar to not having a profile, but when using an unconfined profile, it's possible to replace it with a "real" profile later, so that programs initially running under an unconfined profile get a profile in enforce mode - kill: similar to enforce, but on profile violations, the process will be killed instead of "just" getting EPERM - mixed: when using stacked profiles, this indicates that a program is for example using a stack of two profiles, one in complain and one in enforce mode. (This also means you'll see "mixed" only in aa-status output, but never in a profile's "flags=(...)".) (Extending the aa-* tools to support switching to kill and unconfined mode is still on my TODO list.) b) whitespace changes aa-status was rewritten to C, which results in changed whitespace in the --json output. Currently --pretty-json also results in "compressed" JSON, but I hope that this will change again in the future. I'd guess/hope that whitespace changes shouldn't matter, but please check nevertheless. Currently the new aa-status is only available in upstream git master. If it makes testing easier for you, I can provide the compiled binary or some example output. Regards, Christian Boltz -- Es kann dadurch , daß der Rechner ( wenn er an Trenn - zeichen umbricht [Ratti erklärt ) die falschen Stellen den Begriff erwischt , zu ganz gräß "Plenken" - lichen Effekten kommen in suse-linux] ! -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

11 months, 3 weeks

Re: [yast-devel] Meeting about changes to xml schema

by josef Reidinger

On Thu, 30 Apr 2020 14:24:16 +0100 Imobach González Sosa <igonzalezsosa(a)suse.de> wrote: > El jue, 30-04-2020 a las 12:44 +0200, josef Reidinger escribió: > > On Thu, 30 Apr 2020 12:40:39 +0200 > > josef Reidinger <jreidinger(a)suse.cz> wrote: > > > > > Hi, > > > after modifying xml parser, it appears that our relax ng schema is > > > too strict to allow having type for every xml element. So we should > > > discuss possible solutions. > > > > > > One of solution is to modify our schema to optionally allow that > > > types. I prepare schema change for installation control ( while > > > change for autoyast schema will be needed to do ) and also show > > > example how looks autoyast profile when exported by modified xml > > > parser[1]. If you like typed languages I am sure you will like new > > > xml more then previous :) If not, it still allows to not specify > > > string and map type, just autoyast exported will add it everywhere > > > to handle also empty strings and hashes ( which need it always ). > > > > > > Josef > > > > > > [1] https://github.com/yast/yast-installation-control/pull/96 > > > > Ah, and I forgot to write that meeting will be on Monday after daily > > call at YaST3 at 11:30 CEST. > > Nice, I have added the meeting to the calendar, but I am not sure > whether the time is correct (I would bet that it is wrong). Could > anyone check it? > > Thanks! > Good job, you use correct time. Thanks for adding it. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

11 months, 3 weeks

[yast-devel] Modernizing AutoYaST blog post

by Imobach Gonzalez Sosa

Hi all, We have just published a blog post summarizing some of the ideas related to the "modernizing AutoYaST" initiative. https://yast.opensuse.org/blog/2020-04-30/modernizing-autoyast Not all ideas are there and it is possible that some of them never get implemented. But it is a nice picture of the options we are considering right now. Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/

11 months, 3 weeks

[yast-devel] Meeting about changes to xml schema

by josef Reidinger

Hi, after modifying xml parser, it appears that our relax ng schema is too strict to allow having type for every xml element. So we should discuss possible solutions. One of solution is to modify our schema to optionally allow that types. I prepare schema change for installation control ( while change for autoyast schema will be needed to do ) and also show example how looks autoyast profile when exported by modified xml parser[1]. If you like typed languages I am sure you will like new xml more then previous :) If not, it still allows to not specify string and map type, just autoyast exported will add it everywhere to handle also empty strings and hashes ( which need it always ). Josef [1] https://github.com/yast/yast-installation-control/pull/96 -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

11 months, 3 weeks

Re: [yast-devel] Meeting about changes to xml schema

by Lukas Ocilka

On 4/30/20 12:40 PM, josef Reidinger wrote: > [1] https://github.com/yast/yast-installation-control/pull/96 Checking the PR, I saw a diff from "disksize" to "string". That's right as there's no "disksize" data-type. We have also discussed that we should then modify our control.xml stored on disk during RPM-post-script (which is the right way as `zypper dup` is supported too). But I have a question: what happens in customers' AY profiles actually contain these "disksize" types? Are they going to be invalid? Should we replace/remove them when loading the profile first? I'd like to be careful here, because what used to be valid for ages now turns into invalid because of our internal change. That doesn't sound right even if our intentions were crystal clear. What do you think? Thx 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

11 months, 3 weeks

[yast-devel] AutoYaST tools: feedback wanted

by Imobach González Sosa

Hi all, After doing some research[1] (thanks all for your feedback), the YaST team has started to work on improving AutoYaST. We have identified some areas that we should focus on. One of them, is the process of creating an AutoYaST profile. Creating a profile can be quite challenging, so we offer two different tools to help you in this process: * The "yast2 clone_system" command, which generates a profile with the configuration of the current system. It allows to filter which parts of the profile take into account. * The "AutoYaST UI", which allows to create a profile from scratch (or by cloning the configuration of the current system) and modify the values using a UI. This tool is included in the "autoyast2" package. However, we wonder how do you create your profiles. Do you use any of those tools? Or do you just write some XML yourself? Perhaps you use the tools and tweak the results later... Moreover, we would love to know which problems do you face when you try to create a new profile. Is there anything our tools could do to make your life easier? What about providing some kind of "templates" (minimal, full...) you can tweak? Any other idea? Please, if you can, help us with providing your feedback. Of course, any comment beside these questions is highly appreciated as well. Regards, Imo [1] https://lists.opensuse.org/opensuse-factory/2020-04/msg00291.html -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

11 months, 4 weeks

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

YaST Development April 2020