YaST Development January 2015

yast-devel@lists.opensuse.org

21 participants
41 discussions

[yast-devel] Fixing yast2-slide-show for SLE11 SP3
by Karl Eichwalder 16 Sep '15

16 Sep '15

I want to fix yast2-slide-show for SLE11 SP3. Which git commands do I have to use, please? Thus far, I have checked out trunk only. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 7

[yast-devel] Brainstorming Sessions
by Lukas Ocilka 30 Jan '15

30 Jan '15

Moin, I've discussed this with some of you already. Anyway, for the rest... The problem definition is this: We often have something we'd like to discuss with others and get a quick response. At least I have these quite often. Mailing-list works only partly as people have too much time for their response and sometimes do not respond at all, so quick and still good solution that could be made in 30 minutes takes two weeks. There is a simple solution: Brainstorming - that's proven to bring fast and good ideas (please, +1 if you are interested, -1 if not). How to implement it with distributed team? We have plenty of possibilities: phone conference (people only hear you and you can't share your, e.g., drawings), video conference Orange/Rome (only internal, e.g., Ancor can't join), G+ Hangout (some of you don't like using Google), Internal web-based audio/video system (not tested by me). Other ideas welcomed! How this could work? I'd book some time in everyone's groupwise (1 hour max per week) including a conference room with video system (if needed). Then everyone could mention their theme on the weekly call or via mailing-list and when will the brainstorming happen. Everyone could decide whether to join (or not). Would it help with your issues? It would definitely work for me. Would it also work for you? Other ideas? How is this being done in other teams or in other companies? Thanks Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 6

[yast-devel] YaST2-Journal
by Ancor Gonzalez Sosa 30 Jan '15

30 Jan '15

The yast-journal module is ready to enter YaST:Head. It's already hosted in the yast organization at Github and integrated in Travis with Rubocop, Coveralls (78%), and Yardoc (100%). https://github.com/yast/yast-journal So... 1) ...a warning Last call to suggest an alternative name. 2) ...a question What else do I have to do besides creating the package in OBS/IBS? I have to admit that I have still not taken the time to look close into our Jenkins infrastructure. PS.- The most demanded feature is different colors for the entries (rows on a table) depending on the priority. Is something like that possible with libyui? -- 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

2 1

[yast-devel] overlayfs - why you might not use it
by Steffen Winterfeldt 29 Jan '15

29 Jan '15

Now that overlayfs went into the 3.18 kernel I've had a look if this could be used in our installation environment. = what we need = We have to combine several ro (squashfs) filesystems into the root fs. And the final fs should be writable. Also, it should be possible to easily add and remove fs images. = what we currently do = A script integrates new filesystem images by adding symlinks as needed. = what overlayfs (currently) can do = First, here's how to use it: mount -t overlay overlay -olowerdir=/foo,upperdir=/bar,workdir=/xxx /mnt where /xxx must be on the same fs as /bar but not below /bar. (That's why upperdir must be a writable fs atm, btw.) You can combine exactly *two* filesystems the 'upper' one must be writable. (Doc says you can use two ro filesystems but that is not true atm and there's a note in the sources that they might fix this.) There's no way to combine more than two filesystems except by step-by-step doing overlay mounts. This seems not much of a problem at first but in practice is quite annoying as there are conditions to fulfill; namely you have to have a 'work' directory in the upper fs that must be a separate subtree from the '/' dir in the upper fs. So you would have to make every squashfs writable first by overlaying it with a tmpfs. And then add it to the existing stack. We combine 8 images atm in Factory, so that would be about 16 overlay mounts. Plus you cannot easily unmount parts of this beast as any process rw-opening a file and holding it open (say, even some log or tmp) will block the umount. Plus anything you logged into log files will be lost when you unmount the upper level. This construction seems to be too impractical to me. = conclusion = Not yet. Steffen -- 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] Pending Pull Requests
by yast-ci＠opensuse.org 29 Jan '15

29 Jan '15

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-autoinstallation: - For SLE12-SP1: load release notes of extensions also during AutoYaST (bnc#893586) (41 days) https://github.com/yast/yast-autoinstallation/pull/92 Pending requests in repository yast-bootloader: - SLE12-SP1: initialize bootloader during update if proposed from scratch (bnc#899743) (57 days) https://github.com/yast/yast-bootloader/pull/201 Pending requests in repository yast-network: - Autoyast: do not overwrite firewall settings (7 days) https://github.com/yast/yast-network/pull/275 Pending requests in repository yast-nis-server: - Added command line support for Active Slave sync (33 days) https://github.com/yast/yast-nis-server/pull/6 Pending requests in repository yast-packager: - SLE12-SP1: initialize bootloader during update if proposed from scratch (bnc#899743) (56 days) https://github.com/yast/yast-packager/pull/96 Pending requests in repository yast-theme: - Install scalable icons & fix name of yast-yast-language.* to yast-language.* (153 days) https://github.com/yast/yast-theme/pull/45 Pending requests in repository yast-yast2: - Use native Ruby implementations in Yast::URL and Yast::IP (15 days) https://github.com/yast/yast-yast2/pull/310 Pending requests in repository yast-docker: - Start making this a gem (114 days) https://github.com/yast/yast-docker/pull/2 -- 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] Question about snapper.
by Stef Bon 28 Jan '15

28 Jan '15

Hi, I'm working on a backup program which offers the ability for users to backup a directory based upon mimetypes. Only the mimetypes of choice will be processed. Also it offers access via fuse fs to different versions/snaphots of files, like: sbon [ /srv/backupbtrfs/mount/home/sbon/Projects/fuse/fuse-backup ]$ ls -al fuse-backup-opendir.c total 23 drwxr-xr-x 2 sbon users 11 Jan 28 14:56 . drwxr-xr-x 67 sbon users 4096 Jan 27 19:22 .. -rw-r--r-- 1 sbon users 14041 Jan 23 10:51 201501231350 -rw-r--r-- 1 sbon users 14137 Jan 25 18:06 201501251807 -rw-r--r-- 1 sbon users 14192 Jan 25 23:30 201501252251 -rw-r--r-- 1 sbon users 14210 Jan 26 00:06 201501260032 -rw-r--r-- 1 sbon users 14516 Jan 26 15:57 201501261554 -rw-r--r-- 1 sbon users 14295 Jan 26 15:59 201501261559 -rw-r--r-- 1 sbon users 15681 Jan 27 15:50 201501271440 -rw-r--r-- 1 sbon users 15775 Jan 27 17:53 201501271553 -rw-r--r-- 1 sbon users 15775 Jan 27 18:11 201501271754 -rw-r--r-- 1 sbon users 16244 Jan 27 19:09 201501271816 -rw-r--r-- 1 sbon users 16287 Jan 27 19:22 201501271919 This shows the different versions of the file fuse-backup-opendir.c in /home/sbon/Projects/fuse/fuse-backup. Note that in this fuse fs a file is presented as a directory. This is required to show the different versions as files in this directory. Which directory, and with what options, are processed is stored in a mysql db. It uses btrfs to create snapshots, and rsync to synchronize the directory with the backup. My intention is to create a plugin/extension for filemanagers to get easy access to these versions in a very userfriendly manner. I know snapper offers also backup functionality, and I would like to test it. I've got a recent linuxfromscratch system, so familiar with building from source. Is snapper also possible on other systems than opensuse? Stef Bon -- 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] Cleaner RSpec tests with the new ruby bindings
by Ancor Gonzalez Sosa 28 Jan '15

28 Jan '15

We have just added some RSpec extensions to yast-ruby-bindings (>=3.1.28). As explained in [1], you just need to require "yast/rspec" and you will have some goodies available in the tests, like the shortcuts we all know and love (for creating paths, terms and UI elements) and a #change_scr_root method to safely chroot the tests (with automagic management of the open SCR instance). Refer to the already mentioned documentation for a detailed description and to this commit[2] for some real life examples. Enjoy. As usual, the hardest part was having a starting point. Now it's time to look forward and add more functionality there. What do you miss when writing YaST tests? Which code do you find repeated over and over in YaST tests? Cheers [1] http://www.rubydoc.info/github/yast/yast-ruby-bindings#Testing [2] https://github.com/yast/yast-yast2/commit/b7808cf4d9236e5d1755621f962810735… -- 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

1 0

[yast-devel] Pending Pull Requests
by yast-ci＠opensuse.org 28 Jan '15

28 Jan '15

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-autoinstallation: - For SLE12-SP1: load release notes of extensions also during AutoYaST (bnc#893586) (40 days) https://github.com/yast/yast-autoinstallation/pull/92 Pending requests in repository yast-bootloader: - SLE12-SP1: initialize bootloader during update if proposed from scratch (bnc#899743) (56 days) https://github.com/yast/yast-bootloader/pull/201 Pending requests in repository yast-installation: - SLE12-SP1: allow keyboard layout testing in language dialog (bnc#889549) (54 days) https://github.com/yast/yast-installation/pull/248 Pending requests in repository yast-network: - Autoyast: do not overwrite firewall settings (6 days) https://github.com/yast/yast-network/pull/275 Pending requests in repository yast-nis-server: - Added command line support for Active Slave sync (32 days) https://github.com/yast/yast-nis-server/pull/6 Pending requests in repository yast-packager: - SLE12-SP1: initialize bootloader during update if proposed from scratch (bnc#899743) (55 days) https://github.com/yast/yast-packager/pull/96 Pending requests in repository yast-theme: - Install scalable icons & fix name of yast-yast-language.* to yast-language.* (152 days) https://github.com/yast/yast-theme/pull/45 Pending requests in repository yast-yast2: - Use native Ruby implementations in Yast::URL and Yast::IP (14 days) https://github.com/yast/yast-yast2/pull/310 Pending requests in repository yast-docker: - Start making this a gem (113 days) https://github.com/yast/yast-docker/pull/2 -- 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] Fail fast at Travis?
by Ladislav Slezak 27 Jan '15

27 Jan '15

Hi all, I'd like to discuss one Travis feature here. Currently all Travis steps described in .travis.yml are executed regardless whether something fails or not. The problem is that if any step in the middle fails then it's quite hard to find the issue as the logs are usually very long. For example the yast2 log has over 4500 lines [1]. The question is whether we want to switch to the fail fast principle [2], so the Travis build would stop at the first failure and you could easily find it at the end of the log. (Travis does not support failing fast out of box, but there is a workaround for this [3].) Summary: Current state (always run all steps) + can find multiple issues in a single run - too long log for finding the issues - may report false positives for dependent steps (e.g. if compilation fails then obviously the tests fail too) - longer build times Fail fast + easy to find the failure + failed builds finish faster - you can only see/fix one issue at a time, more iterations for fixing all issues is needed (e.g. you fix a rubocop style issue, but then the testsuite does not pass, after fixing it the install step fails because of a missing change in Makefile... each fix means a new commit and a new build) What do you think about it? Should we change the Travis behavior? [1] https://travis-ci.org/yast/yast-yast2 [2] http://en.wikipedia.org/wiki/Fail-fast [3] https://github.com/travis-ci/travis-ci/issues/1066#issuecomment-32415453 -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 5

Re: [yast-devel] Re: [opensuse-factory] Replacement proposal for the current display-manager.service
by Ancor Gonzalez Sosa 27 Jan '15

27 Jan '15

On 01/27/2015 10:21 AM, Guido Berhoerster wrote: > * Raymond Wooninck <tittiatcoke(a)gmail.com> [2015-01-27 09:56]: >> On Tuesday 27 January 2015 09:44:36 Guido Berhoerster wrote: >>> >>> I don't think it is much of an improvement configuring display >>> manager behavior through /etc/sysconfig/displaymanager while >>> having to select the actual display manager through some other >>> mechanism like update-alternatives. >> >> The question is if those settings in /etc/sysconfig/displaymanager are still >> really affecting the how the display manager works. I know that GDM and KDM a >> lot of their settings are no longer controlled by YaST, but through their >> respective configuration managers. (e.g. Most of the KDM settings are now >> controlled by the KDE systemsettings) >> >> So this would be a good opportunity to really look how and where we want to >> configure our display managers and have a final cleanup of these settings. > > LightDM reads DISPLAYMANAGER_AUTOLOGIN, > DISPLAYMANAGER_PASSWORD_LESS_LOGIN, DISPLAYMANAGER_REMOTE_ACCESS, > DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, DEFAULT_WM. GDM reads > DISPLAYMANAGER_AUTOLOGIN, > DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, and > DISPLAYMANAGER_AUTOLOGIN. LXDM reads DISPLAYMANAGER_AUTOLOGIN and > DEFAULT_WM. With the rest I'm not familiar. The same information for KDM can be found in the comments of this bug report (credits to Wolfgang Bauer) https://bugzilla.suse.com/show_bug.cgi?id=907907 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

1 0

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 January 2015