YaST Development

yast-devel@lists.opensuse.org

2 participants
4459 discussions

Re: [oS-en] What is the meaning of the moon in YaST
by Luna Jernberg 01 Dec '22

01 Dec '22

Hey! The Moon there is to change the Stylesheet/Theme in YaST for Dark Mode or Accessibility modes etc On Thu, Dec 1, 2022 at 1:56 PM Carlos E. R. <robin.listas(a)telefonica.net> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Hi > > When I open the YaST software manager I see at the top right corner, a > moon crescent or wanning (Leap 15.4) > > What is its meaning? > > - -- > Cheers > > Carlos E. R. > (from 15.4 x86_64 at Telcontar) > > > -----BEGIN PGP SIGNATURE----- > > iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCY4ikahwccm9iaW4ubGlz > dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVjKcAn1yNZKpq4mv/gnYPZzYJ > YdyoTzdHAJ9bUnEvw4OcnRF3SCRXLCeVydPkXw== > =2tXb > -----END PGP SIGNATURE-----

1 0

Of D-Installer, xterms and YaST
by Ancor Gonzalez Sosa 01 Dec '22

01 Dec '22

I'm lately a bit busy to take what we, at the YaST Team, call a "learning & innovation day". So I decided to write here a brain-dump of the things I would like to try so others can explore the ideas. First of all, it would be cool to somehow add to D-Installer the possibility to trigger an in-browser terminal like the one offered by Cockpit. When you are using the test ISO you can simply do ctrl+alt+F1. But wouldn't it be cool to have it better integrated and to be able to use it even when you are remotely accessing the web interface of D-Installer (maybe from a tablet or any other system in which you don't have a capable ssh client)?. Moreover, that would imply you would be able to use YaST with its n-curses interface. That should never be needed once D-Installer is feature complete but... let's say you need to format a DASD device to then use it during installation. D-Installer does not yet offer DASD management. Wouldn't be cool to do something like this? 1) Access to D-Installer web interface 2) Open the in-browser terminal 3) Run "yast dasd" there to comfortably manage devices 4) Trigger a device re-scan in D-Installer UI (we don't have such a button yet, but we will need it sooner than later). 5) Adjust the D-Installer storage settings to install in a fresh DASD. The only missing parts would be the terminal (which looks easy to implement using[1] and taking inspiration from Cockpit) and the re-scan button at storage. But, why to stop there? ;-) What if we could make it possible to run YaST modules in a way that is better integrated with D-Installer? I know it's a much crazier idea that makes little sense but, what if I could execute the YaST Partitioner in a terminal in a way in which the resulting staging devicegraph is reflected in the instance of D-Installer (that is, effectively configuring D-Installer storage setup from YaST). Ok, enough. I will go back to work. ;-) Cheers [1] https://www.npmjs.com/package/xterm -- Ancor González Sosa YaST Team at SUSE Software Solutions

1 0

ARIA and the D-Installer
by Ladislav Slezák 28 Nov '22

28 Nov '22

Hi all, recently I did some quick research about ARIA and how we should use it in the D-Installer. Here is a short summary. ARIA = Accessible Rich Internet Applications It's basically a set of attributes for making web applications accessible to people with disabilities. ARIA helps the assistive technologies (like screen readers) to better understand web pages. There is even a W3C specification for it, see [1]. But that is too low-level and boring to read (as specifications usually are). It is much better to start with the Mozilla documentation [2]. At the very begging it mentions two facts: 1. Prefer using semantic HTML elements (like <h?>, <input type="checkbox"> or <button>), these have implicit ARIA attributes and you do not need to specify them. You should use ARIA only for the generic tags (<div>, <span>) or if you use the semantic elements for different meaning (e.g. <ul> is often used for tabs). 2. No ARIA is better than bad ARIA. If you do it wrong then it makes the situation even worse. If you are not sure whether to use ARIA it is safer to NOT use it. I'd add one more fact: 3. Many CSS/JS frameworks define the ARIA attributes themselves (like the PatternFly used by the D-installer). If you use the provided elements properly then you should not need to add/change the ARIA attributes. If we sum up all these items then the result is that we should not take extra attention to the ARIA in the D-Installer unless we get a bug report or we spot a clear need for it. HTH Ladislav [1] https://www.w3.org/TR/wai-aria-1.0/ [2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

D-Installer changelogs update
by Imobach Gonzalez Sosa 25 Nov '22

25 Nov '22

Hi all, To make testing easier, I would like to update D-Installer images after merging each PR. Of course, we could have a "blessed" version in the future for end-users, but I would like to start building the testing image as soon as possible. For that reason, I would like to kindly ask you to update the changes files in each PR. They are in the package/ directory of each module (service, web, cli, image). We do not need to update the version by now. I will do it manually. Regards, Imo -- Imobach González Sosa SUSE Linux LLC

1 0

yast2-theme & yast2-qt-branding-opensuse *require* two different font packages
by Felix Miata 24 Nov '22

24 Nov '22

6 different web browsers I tried won't display <https://fonts.google.com/specimen/Poppins:> "Something went wrong. Please try again soon." I tried <https://fonts.google.com/specimen/Open+Sans> in one browser and it does the same thing. yast2-theme requires google-poppins. yast2-qt-branding-opensuse requires google-opensans. Why are these two font packages required? Is there good reason? What does each font provide that the other doesn't? What do they provide that any other ttf or otf can't that justifies mandatory installation if QT YaST is installed? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

3 2

D-Installer 0.5 released
by Imobach Gonzalez Sosa 21 Nov '22

21 Nov '22

Hi all, We have released a new version of D-Installer which includes quite a lot of changes and fixes: * Add support for basic network configuration, based on NetworkManager (gh#yast/d-installer#260, gh#yast/d-installer#292). * Improve the usability of the LUKS activation dialog (gh#yast/d- installer#253). * Prevent starting the installation with incomplete or wrong configuration (gh#yast/d-installer#299). * Use D-Bus activation instead of explicit service starting (gh#yast/d- installer#287). * Load the configuration from /etc/d-installer.yaml (gh#yast/d- installer#301). * Move D-Bus configuration to /usr/share (gh#yast/d-installer#254). * Extract questions and storage handling to separate services (gh#yast/d-installer#248). * Extend the D-Bus API for the storage proposal (gh#yast/d- installer#268). * Do not block after software installation if a package cannot be installed (gh#yast/d-installer#322). * Add support to install the Adaptable Linux Platform Host OS (gh#yast/d-installer#265). * Update Leap Micro to version 5.3 (gh#yast/d-installer#318). As usual, you can grab the new version from the YaST:Head:D-Installer project: https://build.opensuse.org/package/binaries/YaST:Head:D-Installer/d-install… Please, if you are interested, give the new version a try and report any problem to https://github.com/yast/d-installer Thanks in advance! Regards, Imo -- Imobach González Sosa SUSE Linux LLC

1 0

YaST Team: 11th development report of 2022
by Ancor Gonzalez Sosa 16 Nov '22

16 Nov '22

The YaST team keeps evolving D-Installer without forgetting about YaST itself. News on both fronts include: - Many improvements in D-Installer - The possibility to use SLED on WSL - AutoYaST support for the new security profiles feature - A new tool to visualize installation logs Check the full report at https://yast.opensuse.org/blog/2022-11-16/yast-report-2022-11 Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH

1 0

Re: Community Meeting / D-Installer Workshop: Week 45
by Luna Jernberg 11 Nov '22

11 Nov '22

Did another test with todays D-Installer and installation of Tumbleweed into Virtualbox still works with it :) On Thu, Nov 10, 2022 at 9:02 PM Luna Jernberg <droidbittin(a)gmail.com> wrote: > > Not joining the meeting today, got stuck in Ubuntu and Crystal Linux stuff > > On Mon, Nov 7, 2022 at 2:58 PM ddemaio <ddemaio(a)suse.de> wrote: > > > > Hi all, > > > > The Tuesday meeting tomorrow that takes place at 15:30 UTC will do a > > D-Installer Workshop. Info about this and testing the next gen installer > > can be found it this article > > https://news.opensuse.org/2022/10/27/call-for-testing-next-gen-installer/ > > > > The Community Meeting on Thursdays will take place at 20:00 UTC. > > > > Both meetings take place in https://meet.opensuse.org/meeting > > > > You can see the overview of meeting notes at > > https://etherpad.opensuse.org/p/weeklymeeting > > > > v/r > > Doug

1 0

Logging AutoYaST profile SHA1 checksum
by Ladislav Slezák 07 Nov '22

07 Nov '22

Hi all, recently I was debugging a reported bug in AutoYaST and it turned out that the YaST log does not match the used AutoYaST profile, the log complained about some wrong custom script but the attached profile did not define anything like that. In this case we could relatively easily find out that the attached profile was not the profile which was really used by AutoYaST. But in other cases it might be more difficult or even impossible. We cannot log the whole AY profile for security reasons (it might contain registration keys, user passwords or other sensitive data) so I slightly improved logging in the "master" branch. Now AutoYaST logs the SHA1 checksum of the profile and rules or classes files if they are used. Then you can easily get the checksum of the attached profile by using a command like "sha1sum autoyast.xml". The checksum must be the same as logged by YaST, simple "grep SHA1 y2log" should find it. If the checksum is not the same than the file used by YaST was different. (Note: This compares the files bitwise, e.g. adding a newline at the end of a XML file does not change the logical content but the SHA1 will be completely different. But as you cannot be sure what users actually changed it should be always a good idea to ask for the real file.) See more details in the GitHub pull request https://github.com/yast/yast-autoinstallation/pull/857 -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

Testing d-installer in qemu aarch emulation
by josef Reidinger 02 Nov '22

02 Nov '22

Hi, just if someone wants also give a try d-installer in qemu emulation. I tried it on my local machine and speed is not so bad, but it reveal a weak point which can maybe affect also other weaker machines when using d-installer. It failing in systemdd service and even if run manually with `d-installer`. If you run d-installer as one binary that start others with 1s delay[1] between services does not need to be enough and due to race condition some service can fail due to missing required dbus interface that is not yet exported. As workaround run each service separately and for each wait when it really start exporting interface. Maybe it is time to fix TODO and implement better way? It can help with low-end machines. And with workaround it works and I can reproduce issue on aarch64.[2] Josef [1] https://github.com/yast/d-installer/blob/master/service/bin/d-installer#L56 [2] https://github.com/yast/d-installer/issues/279#issuecomment-1299236944

3 2

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

YaST Development