July 2014 - YaST Development - openSUSE Mailing Lists

[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] rspec 3.0
by Josef Reidinger 17 Dec '14

17 Dec '14

Hi, in this blog post http://myronmars.to/n/dev-blog/2014/05/notable-changes-in-rspec-3 is summary of changes in new rspec 3.0. I do not think that we will use it for SLE-12 tests, but maybe it will be used for 13.2. In general I think we should not use new syntax now, but what we can do is to not use deprecated syntax as there is already alternatives to prevent future problems. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

5 5

[yast-devel] who is the maintainer?
by Arvin Schnell 08 Dec '14

08 Dec '14

Hi, while reassigning yast-maintainers bugs I noticed that once again the maintainer/bugowner information is inconsistent: The content of the MAINTAINER file in git differs from the output of 'osc maintainer' or 'osc bugowner'. This leads to confusion. We had this problem before and apparently fail to solve the inconsistency long term. So I propose to drop the MAINTAINER file in git and rely on osc. Instead we can have a AUTHORS files so that people not knowing about osc can still reach the authors. Regards, Arvin -- 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] Why not place refactoring in backlog
by Josef Reidinger 08 Aug '14

08 Aug '14

Hi, I found this nice article[1] that nicely and visible summarize all my arguments why refactoring should not be separated tasks, but integral part of all work. I think it deserve reading. Josef [1] http://xprogramming.com/articles/refactoring-not-on-the-backlog -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

5 7

[yast-devel] very unimpressed by found changes
by Felix Miata 04 Aug '14

04 Aug '14

Via HTTP I just did my first Factory installation in several months. White on brown is ugly. Is there or will there be an option for an installation GUI theme more like the old, black text on light background, with visible borders, scrollers, and tabs where applicable? Red on brown (in changes to partitioning) is barely legible. Green on brown on summary screen is virtually invisible. I can tell something is there, but not what it says, and there is no popup to explain whatever is hovered. In expert partitioner, there are "checkboxes" lacking boxes. I don't like that either. Once they are all unchecked, there is nothing to indicate boxes exist, much less where they are. This particular section has always puzzled me: "visible information on storage devices" for what (installation summary/storage settings) purpose? When I open Fstab options after having selected volume label as the default mount by, why for a freshly formatted target / partition with volume label is UUID preselected instead of Volume Label? Seeing parts of the content of the fullscreen "Edit Partition /dev/sda16" spilling out from under that (apparently) borderless brown void that is the Fstab options "window" is seriously unimpressive. In detailed software selection those itty bitty things in left pane apparently representing checked boxes need to be much bigger to tell that's what they're supposed to be. Choice between no bootloader and Grub2 is very Fedora-ish, would cause all my installations to be much more complicated, since I have no need and thus no use for the overcomplicated monster (to be obsoleted in not too distant future by UEFI) that is Grub2. Since Grub remains available to select among packages, will it be possible to set it up from running the grub shell on tty2 before rebooting from the installer (I tried simply 'grub', which produces command not found from bash)? Towards the end it claimed to be installing boot manager even though Grub2 was tabooed, produced no error message. Neither did it leave a /boot/grub/menu.lst to be used as configfile from elsewhere, though it did produce a device.map. /etc/sysconfig/bootloader is too stripped to be useful. Trying to chainload it produced the invalid executable format message I'm used to seeing on installations containing no bootloader on /. I copied and edited menu.lst from 13.1 for now, and gfxboot and perl-Bootloader apparently work as always even though I had to manually configure Grub. y2logs: http://fm.no-ip.com/Tmp/SUSE/y2l-gx28b-os132-201407.tgz -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

5 11

[yast-devel] sle12 network config in linuxrc
by Steffen Winterfeldt 01 Aug '14

01 Aug '14

As the latest linuxrc with the new network code mostly active accidentally slipped into rc1, I better describe the changes now. :-) == network config before sle12 == ** These options are still available in sle12. ** If the repo location is a network url you either get a dhcp config or can supply a static config, e.g. hostip=10.0.1.1/24 gateway=10.0.1.254 nameserver=10.0.1.2 domain=suse.de This config is tried on every network interface in turn until it works. If you don't have a network repo you can still get a network config by netsetup=1 Also, if you do an ssh or vnc installation, linuxrc knows you'll need a network config. The major drawback here is that you can only configure a single interface. == network config in sle12 == That's why there is now the new 'ifcfg' option. The example above would look like static: ifcfg=*=10.0.1.1/24,10.0.1.254,10.0.1.2,suse.de dhcp: ifcfg=*=dhcp The general syntax is ifcfg=interface_name_or_pattern[.vlanid]=ip_addr_list,gateway,namserver_list,ns_search_list[,any_ifcfg_option=foo,...] ifcfg=interface_name_or_pattern[.vlanid]=dhcp[46] It will create ifcfg/ifroute files for all matching interfaces (dhcp) resp. the first matching interface (static setup), then run 'wicked ifup all' and if wicked managed to bring up at least one interface, assume that tings worked. ip_addr_list and namserver_list are space-separated lists, so don't forget to quote the 'ifcfg' option value. If you use a wildcard pattern, it is matched against all existing interfaces and mac addresses; if you use just an interface name, a config is created regardless whether the interface exists. A wildcard pattern will never match 'lo'. You can have several 'ifcfg' options, of course. Advantages: - more than one interface can be configured - supports vlan setup (e.g. ifcfg=eth0.55=dhcp) - can set arbitray ifcfg options (ifcfg=eth3=dhcp,STARTMODE=nfsroot) - no trial-and-error on all interfaces Note: the transition to the new code is WIP. You may find occasionally that linuxrc thinks the network is not configured even though it really is. Steffen -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 5

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

31 Jul '14

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-theme: - A stub of a README. (5 days) https://github.com/yast/yast-theme/pull/40 Pending requests in repository yast-cio: - Coverage with Travis and Coveralls (20 days) https://github.com/yast/yast-cio/pull/7 -- 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 30 Jul '14

30 Jul '14

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-theme: - A stub of a README. (4 days) https://github.com/yast/yast-theme/pull/40 Pending requests in repository yast-cio: - Coverage with Travis and Coveralls (19 days) https://github.com/yast/yast-cio/pull/7 -- 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 Jul '14

29 Jul '14

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-cio: - Coverage with Travis and Coveralls (18 days) https://github.com/yast/yast-cio/pull/7 -- 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] yast Mode.* variables
by Steffen Winterfeldt 28 Jul '14

28 Jul '14

Having just learned about the Mode.autoupgrade variable I did some research and found a total of 12 instances of Mode.* (maybe I missed some): Mode.autoinst Mode.autoupgrade Mode.commandline Mode.config Mode.installation Mode.live_installation Mode.normal Mode.repair Mode.screen_shot Mode.test Mode.testsuite Mode.update I think they should not only be prominently documented but preferably the number should be reduced. They are a nuisance and one of the reasons yast is so hard to debug. There's always some use case with some unexpected combination of them. This just asks for trouble. IMO Steffen -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

6 9