January 2015 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Tumbleweed - what is TW based on?
by Basil Chupin 09 Feb '15

09 Feb '15

What is Tumbleweed based on? I was under the assumption that TW was based on oS 13.2 and that it was the "rolling version" of oS 13.2. But is it? If TW *is* based on 13.2 then why doesn't the list of Repositories in YaST show all the Community Repositories as in 13.2 but adjusted to read "......openSUSE_Tumbleweed"? If it *isn't" based on 13.2 then why couldn't the list of Repositories in YaST be made to show all the repos. for Tumbleweed anyway? Heck, someone download the latest massive 4.3GB DVD of Tumbleweed and then has no idea that there are repositories that should be installed to make it worth while to use. The instructions in https://en.opensuse.org/Tumbleweed are deficient and do no do justice to the software (or the community). I keep reading posts here after a new "daily" "2015xxyy" ISO of TW is released stating that this or that does not work or TW won't install et al.. (An aside: I installed yesterday 20150123 on my Lenovo laptop and have no problems with the network either cable or wi-fi.) Add to this the absence of any acknowledgement that there are repositories available for TW but which are not mentioned anywhere then TW becomes a "lame duck" from trying to make it a "rolling release" of the finest Linux distros around. BC -- Using openSUSE 13.2, KDE 4.14.3 & kernel 3.18.3-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

13 44

[opensuse-factory] Enabling PIE globally
by Marcus Meissner 05 Feb '15

05 Feb '15

Hi, short: Marcus wants to enable PIE support globally. long version: To make programs less affected by buffer overflows and similar exploits, one feature is "address space layout randomization" aka "ASLR". We randomize various parts of the address space already, stack, mmaps, libraries and the vdso. e.g. for /usr/bin/cat: cat /proc/self/maps 00400000-0040c000 r-xp 00000000 08:01 397387 /usr/bin/cat 0060b000-0060c000 r--p 0000b000 08:01 397387 /usr/bin/cat 0060c000-0060d000 rw-p 0000c000 08:01 397387 /usr/bin/cat binary not randomized. 007d5000-007f6000 rw-p 00000000 00:00 0 [heap] heap not randomized. 7f530a549000-7f530a6ee000 r-xp 00000000 08:01 220 /lib64/libc-2.18.so ... 7f530ab17000-7f530ab18000 rw-p 00020000 08:01 52 /lib64/ld-2.18.so 7f530ab18000-7f530ab19000 rw-p 00000000 00:00 0 7fff71086000-7fff710a7000 rw-p 00000000 00:00 0 [stack] 7fff711fa000-7fff711fc000 r-xp 00000000 00:00 0 [vdso] everything randomized ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] not randomized, but should be safe To randomize the binary and heap the binary needs to be packaged using the PIE options of the compiler. (PIE == Position Independend Executable) This needs to be done during compilation (-fPIE) and during linking (-pie), which makes it harder to implement. Advantages of PIE: - a bit more secure (e.g. the major "codename" issues from 2014 (Heartbleed, Shellshock, Poodle) would not have been avoided...) Disadvantages of PIE: - There had been performance concerns, but these are mostly relevant for i586 due to low number of processor registers (and there like 5-10%). On other platforms but i586 there should be no performance decrease. I adjusted some endangered packages manually, but it would be better to do this globally. Just changing %optflags / RPM_OPT_FLAGS is insufficient as the linker also needs to be called specifically and this cannot be passed in via the configuration. Methods I am currently thinking about: - Change the compiler directly to build PIE binaries by default (change in gcc) Binaries that do not want it, would need to use -no-pie / -fno-PIE Advantage: - only some changes in .spec file where it is not wanted - would work for more than just the spec files using %configure or %cmake macros - Change the %configure RPM macro to pass the PIE flags in by default (change in rpm) Advantage: - only some .spec files need to be changed where it is not wanted Disadvantage: - %configure would need an option to disable PIE for apps that break (- manually changing all RPMs: not feasible) Any comments? I would try to work the gcc approach when I am back to work as time permits :/ Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

10 24

[opensuse-factory] Replacement proposal for the current display-manager.service
by Raymond Wooninck 03 Feb '15

03 Feb '15

Hi Everyone, The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started. Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working. My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself. One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use. The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files. The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager. I would appreciate on-topic replies, feasibility of a proposal and which proposal would be preferred. Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

14 35

[opensuse-factory] can if-up/if-down networking be restored to 13.2 to replace wicked until it's fixed?
by grantksupport＠operamail.com 03 Feb '15

03 Feb '15

Upgrade from 13.1 -> 13.2 removed support for traditional/stable if-up/if-down network control, replacing it with wicked. In 13.2, wicked's currently badly broken; there are existing/critical issues, that prevent production use; those issues include, among mounting others, e.g., (1) tun https://bugzilla.suse.com/show_bug.cgi?id=904903 (2) up/down script usage https://bugzilla.suse.com/show_bug.cgi?id=907215 (3) ipv6 https://bugzilla.suse.com/show_bug.cgi?id=907694 Those issues need fixing, and are getting some attention already. In current state, these network problems leave 13.2 unstable at best, unusable at worst. In 13.1 all the aforementioned issues are not a problem -- everything was working. IMO, disabling working if up/down prior to full-release-vetting of wicked et al is an operational mistake. We'd prefer to stay with 13.2 .... but our available production solutions atm are (1) downgrade 13.2 -> 13.1 (2) switch to a known/working other distribution (Redhat/Centos 7, e.g.) (1) is messy and painful, and functionally regresses many of the OTHER solutions that modern/current 13.2 brings. (2) is what we've done -- currently at all our production/edge boxes. In lieu of immeidate fixes to 13.2, is it possible to reenable 'old' ifup/ifdown networking, disabling wicked, so we can get the distro back to working/production state? Or is wicked simply too wired-into 13.2? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

10 13

[opensuse-factory] util-linux
by Ruediger Meier 02 Feb '15

02 Feb '15

Hi, IMO our util-linux package is completely messed up. Last year I had spend a lot of time to simplify it, to bring patches upstram etc. But some weeks later after update to 2.25 was finished it became even worse than before. Somehow it was required to split the package into 3 packages to prevent build loops (python, systemd deps)... This split made the spec file unreadable und IMO unmaintainable. Just have a look how the configure.ac and Makefiles are raped in 3 different ways by dozens of nested, ifdef'ed sed lines. Is there really no other way to solve these build loops? cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 13

[opensuse-factory] RE: Export broken for KinfoCenter
by Andre Verwijs 30 Jan '15

30 Jan '15

Bug already exits bug nr. 315702 i will add a comment there.... Thank you :) _____________________________________________________________________________________ My Twitter Page (follow me please) http://twitter.com/OpenSimFan My Facebook page (Become my friend please...:) ) http://www.facebook.com/andre.verwijs My Google+ page (Follow me please...:) ) https://plus.google.com/111310545842863442992 .. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] Export broken for KinfoCenter
by Roger Luedecke 30 Jan '15

30 Jan '15

Export button is greyed out no matter what. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] Presenting python-sh
by Alberto Planas Dominguez 30 Jan '15

30 Jan '15

Hello openSUSE I would like to include python-sh into Factory. python-sh is a Python library that allows you to interact with the shell script. You can call any external application from Python, in a coherent way. For example import sh print sh.ls('-l', '-a') print sh.pwd() This will call `ls -l -a` and `pwd` and print the result in the console. Is powerful and really convenient when you want to replace shell scripts with a more productive language. If no one is against this, I would like to create the request the next Monday. Thanks, Alberto Planas -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] shutdown has stopped working
by Constant Brouerius van Nidek 30 Jan '15

30 Jan '15

For some days I found that shutdown -r now does not work anymore. The machine freezes and only the rest button solves a reboot. The function in the menu gives the same result. Tried to find out where a log about this event could be found in order to start solving my problem. Could somebody give me helping hand? The system is up to date with version 20150129 just downloading. -- Linux User 183145 using Tumbleweed KDE4 and LXQT on a Pentium IV , powered by openSUSE 20150127 (i586) Kernel: 3.18.3-1-default KDE Development Platform: 4.14.4 20:37pm up 0:46, 3 users, load average: 1.38, 0.86, 1.34 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] libspf2, perl-Mail-SPF, and /usr/bin/spfquery
by Lars Müller 30 Jan '15

30 Jan '15

Hi, exim got an enhanceent and now requires libspf2. The suggested package also includes some binaries, in particular spfquery which is also provided by perl-Mail-SPF The binaries are in the spf2 package and as spf_example already came with an underscore in it I decided to go the easy way and renamed /usr/bin/spfquery to /usr/bin/spf_query to avoid the potential file conflict. Debian makes use of update-alternatives. But I'm not sure if it's worth the effort. If someone implements it or has a patch ready, feel free to file a submit request against libspf2 and perl-Mail-SPF. Cheers, Lars PS I thought I had written this mail before but had not been able to find it in the archive. -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

1 1