March 2014 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] acpid requires systemd?
by Felix Miata 25 Apr '24

25 Apr '24

Can this be true? If so, why? Zypper won't let me upgrade acpid without breakage unless systemd is installed too. I have systemd locked out, as I'd rather test things I can understand in Factory, not major overhaul stuff. -- "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: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

4 3

Re: [opensuse-factory] repository priorities with Tumbleweed
by Thomas Langkamp 16 Jul '15

16 Jul '15

> No, please don't confuse people, if you add more repos than just > Tumbleweed you really had better know what you are doing or bad things > can, and will, happen :) I understand. I just would like to add the following to http://en.opensuse.org/Portal:Tumbleweed - between ## is the new stuff: "The only supported method of repo use for Tumbleweed is to have only the main repos (Oss, Non-oss, and Update) and the Tumbleweed repo active. ## If you use more repositorys you have to know how repo-priorities work, but even then Tumblweed does NOT support this ## " It would also be good to move this information to "Special concerns" and to move the whole "Special concerns"-section up. For example "Special Concerns Virtual Machines ... Third Party Drivers ... ## Non-Standard Repos: Only use Oss, Non-oss, and Update combined with the Tumbleweed-Standard repo. Everything else is not supported and might break the system ## " >You do know the legal reasons behind why packman is there, right? Yes. Then I do not whish you personaly to support Packman with TW - I understand now that this is not possible from your perspectivg. But...as the OS community discusses right now if/how to strengthen Tumbleweed... one way would be, that Packman+TW would be supported BY Packman. So I will ask the Packman-guys to do that... I hope this is possible for them. Without Packman Tumbleweed is so ... "anti-multimedia" ;) thanks anyway :D -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

11 18

[opensuse-factory] openSUSE:Factory:NonFree repository
by Kyrill Detinov 03 Jul '15

03 Jul '15

Hello. /factory/repo/non-oss/ isn't updated since September 23. -- WBR Kyrill

4 9

[opensuse-factory] Monospace font issue
by Kyrill Detinov 07 Apr '15

07 Apr '15

Hello. Recently updated my Factory running workstation (x86_64, Xfce). Monospace font interval is increased badly. I'm sure, I use DejaVu Sans Mono as a monospace font. I choose 'monospace 9' in programs settings. There is a screenshot: http://susepaste.org/view/simple/38919191 Changing to 'DejaVu Sans Mono 9': http://susepaste.org/view/simple/70371539 It looks like it was before. % fc-match Monospace Fontconfig warning: "/etc/fonts/conf.d/56-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. please move it to /home/kent/.config/fontconfig/fonts.conf manually Monospace: "Monospace" "Regular" -- WBR Kyrill

9 23

[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] systemd version 210 Heads Up
by Raymond Wooninck 22 Nov '14

22 Nov '14

Hi List Mates, Just a very early warning with regards to the latest released systemd version (version 210). In the release notes the following two items will have an effect on people that are utilizing laptops with a docking station and an external monitor. * logind is now a lot more aggressive when suspending the machine due to a closed laptop lid. Instead of acting only on the lid close action it will continuously watch the lid status and act on it. This is useful for laptops where the power button is on the outside of the chassis so that it can be reached without opening the lid (such as the Lenovo Yoga). On those machines logind will now immediately re-suspend the machine if the power button has been accidentally pressed while the laptop was suspended and in a backpack or similar. * logind will now watch SW_DOCK switches and inhibit reaction to the lid switch if it is pressed. This means that logind will not suspend the machine anymore if the lid is closed and the systemd is docked, if the laptop supports SW_DOCK notifications via the input layer. Note that ACPI docking stations do not generate this currently. Also note that this logic is usually not fully sufficient and Desktop Environments should take a lid switch inhibitor lock when an external display is connected, as systemd will not watch this on its own. The first item concerns a change that systemd is monitoring if the lid is closed or not. This monitoring starts already during the system boot process which would lead to the effect that the system is forced into suspend mode even before the login manager is reached. To prevent this, the second item was implemented, however as indicated current kernels (including the latest 3.14- rc4) do not support this yet for all laptops. The issue however is that the system will not reach the Desktop Environment yet as that this new principle already kicks in during the boot process. So implementing a lid switch inhibitor in GNOME/KDE/etc does not make any sense as that the system will never reach the desktop environment. I had a couple of email conversations with Lennart about this topic yesterday and finally with my last message he got the real issue that this happens during system boot and therefore systemd should handle this properly. He indicated that he will resolve the issue in one of the upcoming versions of systemd and also probably move the external monitor detection out of the DEs into logind. (The situation will then be that if the lid is closed and an external monitor is connected, then systemd will not suspend the system). If the decision is taken by the systemd maintainers, then in my opinion it would be good to revert the two commits in systemd version 210 that implement the two items mentioned so that the old lid switch behavior is restored. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

16 49

[opensuse-factory] Devel Project Virtualization: Not built against Tumbleweed?
by Johannes Kastl 15 Nov '14

15 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, while updating lxc to the latest version I came across one question: Is there any particular reason, why the virtualization-project (https://build.opensuse.org/project/show/Virtualization) is not built against/for tumbleweed? If not, could one of the maintainers please correct that? Regards, Johannes - -- You know the world is going crazy when the best rapper is a white guy, the best golfer is a black guy, the Swiss hold the America's Cup, France is accusing the US of arrogance, and Germany doesn't want to go to war. (aus alt.jokes) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlMh+nYACgkQzi3gQ/xETbKLxwCfajUC5ZU1bCAghqGNY1u5eOyO GFsAn3njjuzTONetwWTIaNAdNVVA0gSP =RhDV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 13

[opensuse-factory] Tumbleweed: systemd cannot start privoxy
by Patrick Shanahan 30 Oct '14

30 Oct '14

up to date Tumbleweed (13.1) systemctl start privoxy 18:26 Crash: ~ # systemctl start privoxy Job for privoxy.service failed. See 'systemctl status privoxy.service' and 'journalctl -xn' for details. 18:27 Crash: ~ # systemctl status privoxy privoxy.service - Privoxy Web Proxy With Advanced Filtering Capabilities Loaded: loaded (/usr/lib/systemd/system/privoxy.service; disabled) Active: failed (Result: exit-code) since Wed 2013-11-20 18:27:09 EST; 15s ago Process: 9430 ExecStart=/usr/sbin/privoxy --pidfile /run/privoxy.pid --user privoxy /etc/privoxy/config (code=exited, status=1/FAILURE) Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... Nov 20 18:27:09 Crash systemd[1]: privoxy.service: control process exited, code=exited status=1 Nov 20 18:27:09 Crash systemd[1]: Failed to start Privoxy Web Proxy With Advanced Filtering Capabilities. Nov 20 18:27:09 Crash systemd[1]: Unit privoxy.service entered failed state. 18:27 Crash: ~ # journalctl -xn -- Logs begin at Sat 2013-03-30 18:27:22 EDT, end at Wed 2013-11-20 -- 18:27:35 EST. -- Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... -- Subject: Unit privoxy.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit privoxy.service has begun starting up. Nov 20 18:27:09 Crash systemd[1]: privoxy.service: control process exited, code=exited status=1 Nov 20 18:27:09 Crash systemd[1]: Failed to start Privoxy Web Proxy With Advanced Filtering Capabilities. -- Subject: Unit privoxy.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: -- http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba4… -- -- Unit privoxy.service has failed. -- -- The result is failed. Nov 20 18:27:09 Crash systemd[1]: Unit privoxy.service entered failed state. Nov 20 18:27:15 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=282 TOS=0x00 PREC=0x00 TTL=64 ID=51684 DF PROTO=UDP SPT=631 DPT=631 LEN=262 Nov 20 18:27:15 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=282 TOS=0x00 PREC=0x00 TTL=64 ID=51685 DF PROTO=UDP SPT=631 DPT=631 LEN=262 Nov 20 18:27:34 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=247 TOS=0x00 PREC=0x00 TTL=64 ID=51686 DF PROTO=UDP SPT=631 DPT=631 LEN=227 Nov 20 18:27:34 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=247 TOS=0x00 PREC=0x00 TTL=64 ID=51687 DF PROTO=UDP SPT=631 DPT=631 LEN=227 Nov 20 18:27:35 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=263 TOS=0x00 PREC=0x00 TTL=64 ID=51688 DF PROTO=UDP SPT=631 DPT=631 LEN=243 Nov 20 18:27:35 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=263 TOS=0x00 PREC=0x00 TTL=64 ID=51689 DF PROTO=UDP SPT=631 DPT=631 LEN=243 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

9 20

[opensuse-factory] New Package - libhal1-flash (re-enabling Flash-Player DRM content on Linux)
by Christopher Horler 13 Sep '14

13 Sep '14

Good afternoon! I've written and packaged a compatibility library for flash to enable playback of DRM content (this removes the dependency on the HAL package). I'd like to know what steps I can take to have the package considered for inclusion in openSUSE 12.3 and 13.1. Can I submit the package to devel:openSUSE:Factory, or is there another action I should be taking? Details of the bug and links to upstream are here (please briefly review): https://bugzilla.novell.com/show_bug.cgi?id=768562#c19 OBS location: https://build.opensuse.org/package/show?package=hal-flash&project=home%3Ach… I will maintain the package until such time that HTML5 Video content is a viable alternative or the Flash plugin is completely withdrawn. RPMs, debs... are all available on the build service. Three noteworthy points: - package naming (libhal1-flash) doesn't 100% align with the Shared Library Policy (I've suffixed -flash to make clear this is not a fully functional HAL layer and also to avoid naming conflicts as some distros seem to have a shared library package already named libhal1). - The packages depends on dbus and udisks. It seems to work find when udisks is launched on demand (as for openSUSE 12.3) - The flash-player package could have some kind of RPM dependency on this package to assist the user when looking in YaST (Install / Remove Software) / Package Manager. Chris -- 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] source_validator error: signature does not validate
by Kyrill Detinov 25 Aug '14

25 Aug '14

Hello. I can't build a package. Service source_validator failed. % osc build Run source service: /usr/lib/obs/service/format_spec_file --outdir /tmp/tmpVbBhay Run source service: /usr/lib/obs/service/source_validator --outdir /tmp/tmpIQYU6i /home/kent/rpmbuild/projects/M17N/i18nspector/i18nspector.keyring gpg: enabled debug flags: memstat gpg: keyring `/tmp/check_if_valid_source_dir-NL8Ezs/.checkifvalidsourcedir-gpg-keyring' created gpg: Oops: keyid_from_fingerprint: no pubkey gpg: Oops: keyid_from_fingerprint: no pubkey gpg: key 00000000 occurs more than once in the trustdb gpg: key 015475F5: public key "Jakub Wilk <jwilk(a)jwilk.net>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/32768 bytes in 0 blocks gpg: enabled debug flags: memstat gpg: Signature made Mon Jun 24 22:36:51 2013 MSK using RSA key ID 015475F5 gpg: Oops: keyid_from_fingerprint: no pubkey gpg: Oops: keyid_from_fingerprint: no pubkey gpg: key 00000000 occurs more than once in the trustdb gpg: Good signature from "Jakub Wilk <jwilk(a)jwilk.net>" gpg: aka "Jakub Wilk <jwilk(a)debian.org>" gpg: aka "Jakub Wilk <ubanus(a)users.sf.net>" random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/32768 bytes in 0 blocks (E) signature /home/kent/rpmbuild/projects/M17N/i18nspector/i18nspector-0.11.1.tar.gz.asc does not validate Aborting: service call failed: /usr/lib/obs/service/source_validator --outdir /tmp/tmpIQYU6i Source service run failed! As far as I can see, the signature is good. This also happens with another package (graphics/icoutils). What is the problem? -- WBR Kyrill

2 5

[opensuse-factory] what happened to fbset?
by Felix Miata 04 Aug '14

04 Aug '14

in 11.4: # fbset -i mode "1152x864" geometry 1152 864 1152 864 32 timings 0 0 0 0 0 0 0 accel true rgba 8/16,8/8,8/0,0/0 endmode Frame buffer device information: Name : radeondrmfb Address : 0xd80c0000 Size : 3981312 Type : PACKED PIXELS Visual : TRUECOLOR XPanStep : 1 YPanStep : 1 YWrapStep : 0 LineLength : 4608 Accelerator : No In 13.1B1: # fbset -l if 'fbset' is not a typo, You can use... # zypper se -s fbset ... No packages found. # command-not-found fbset fbset: command not found -- "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: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 18

[opensuse-factory] OSEP: openSUSE Distribution Daemon User and Group Names
by Guido Berhoerster 29 Jul '14

29 Jul '14

Hello, after initial discussion on the -packaging list (see http://lists.opensuse.org/opensuse-packaging/2014-02/msg00136.html) and incorporating some of the feedback we would like to introduce the attached openSUSE Enhancement Proposal about creating a safe namspace of system user and group names. Further comments and reviews would be appreciated. Full text of the OSEP (currently maintained at https://github.com/lnussel/osep_opensuse_usernames/blob/master/opensuse_use…): _____________________________________________________________________ OSEP: XXXX Title: Informational proposal: openSUSE Distribution Daemon User and Group Names Version: 0.1 Last-Modified: 03 Mar 2014 Author: Guido Berhoerster <gber(a)opensuse.org>, Ludwig Nussel <ludwig.nussel(a)suse.de> Status: Draft Type: Informational Created: 28 Feb 2014 Post-History: _____________________________________________________________________ Abstract -------- This OSEP proposes a defined pattern for unprivileged system user and group names. Specification ------------- Packages that add unprivileged users to e.g. run daemons as need to use names that follow the following regular expression: ^_[0-9a-z][0-9a-z_]*$ This policy is meant to be applied to all packages that are new to openSUSE Factory. Existing packages are encouraged to switch to the new policy. An exception are legacy users with a static uid as created on first installation by aaa_base, like e.g. 'root' or 'nobody'. Motivation ---------- Many packages need to add user and group names for their unprivileged daemons. Currently openSUSE Factory has a known lists of more than 130<<A>> such daemon user names. Many names are short for convenience, e.g. 'pop', 'vdr', 'tor' or 'znc'. Since there is no separate name space for system users those names may collide with names of real persons. A common pattern for user names on unix systems also is to combine letters of the given names and the surname which may lead to combinations that may also collide with system user names. Sharing a user name between a system user and a normal user leads to surprising or even security relevant misbehavior as the daemon user may write to files in the real user's home or vice versa. Since introducing a separate namespace is not possible in the current name service model, separating system users and real users must be done by naming them differently. Rationale --------- A special prefix or suffix to user names is a straight forward solution to the same namespace problem. Since long user names may not fully be displayed by e.g. the ps tool the chosen method needs to be short. Therefore using a single letter character may be used. According to the recommended regular expression for usernames in the useradd manpage<<D>> of the shadow package, dollar could be used as suffix or underscore as prefix or suffix. OpenBSD already implemented a policy to use underscore (ASCII character 95) as prefix in 2003<<C>>. This method is therefore considered proven in practice. For symmetry reasons and because many packages also create groups with the same name as the user the same solution should be applied to groups as well. License ------- This document has been placed in the public domain. References ---------- [bibliography] - [[[A]]] current list of known user names in opensuse is maintained in link:https://build.opensuse.org/package/view_file/openSUSE:Factory/rpmlint/… - [[[B]]] link:http://anonscm.debian.org/viewvc/pkg-shadow/upstream/trunk/man/useradd… manpage] - [[[C]]] List of sytem users in link:http://www.openbsd.org/cgi-bin/cvsweb/\~checkout~/ports/infrastructure… with short sentence expressing the "policy" - [[[D]]] some link:http://lists.opensuse.org/opensuse-packaging/2014-02/msg00103.html[num… collected by Guido -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

20 64

[opensuse-factory] libav and multimedia idea
by Tomáš Chvátal 14 May '14

14 May '14

Hello guys, I have created proof of concept libav library with disabled patented codecs in my home project [1]. This means that this library si up par with what we have in chromium and it should be legal to distribute. Apart from the library the repo contains vlc chromium and xbmc (built localy fails on obs, meh) which seems to run fine, just not to play almost anything ^_^. The possibility here is to include all the media players and stuff around it into openSUSE release, where one has to flip the switch in libav (see the spec file) and can build full-fledged-european-edition which can play our sweet movies. Let me know what you think about this plan and what would you use as base devel project for this. Cheers Tom [1] https://build.opensuse.org/project/show?project=home%3Ascarabeus_iv

8 11

[opensuse-factory] [Tumbleweed] libkmod: conf_files_list: unsupported file mode /dev/null: 0x21b6
by Achim Gratz 16 Apr '14

16 Apr '14

I'm gettin reams of these messages whenever zypper creates new initrd. It looks like there's a patch for this problem available: http://www.spinics.net/lists/linux-modules/msg01240.html Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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] journald configuration defaults
by Achim Gratz 14 Apr '14

14 Apr '14

Some time ago I had a problem with slow boot. Once that was fixed I started to have the opposite problem, that is long delays with high disk activity during shutdown, getting much worse with time. Again this turns out to be triggered by journald: once the log file had grown past 20MiB or so there would be a noticeable delay when flushing the log to disk and it became unbearable at 80MiB. The time is superlinear with log size: a verify on the current 7MiB journal file takes roughly 1.5s (17s for a loop of 16 verifies), the 114MiB for the old file are already over 30s. The solution (for me) was to set SystemMaxFileSize=8M in /etc/systemd/journald.conf so that the active journal file gets rotated much earlier than with the built-in defaults. I have a rather small separate /var, but that file would have grown to about 300MiB. considering that most people probably have probably much larger /var partitions and the superlinear scaling characteristics, I think it would be advisable to provide more sensible defaults with the distribution. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 18

[opensuse-factory] VDR update in planning
by Stefan Seyfried 11 Apr '14

11 Apr '14

Hi all, i'm finally trying to tackle https://bugzilla.novell.com/836149 -- that is, update VDR to version 2.x My plan is to use a mix of home:balta3:vdrdevel and home:frispete:vdr2 (which partly links to the former). Hans-Peter has kept the vdr.spec based on the one in the vdr repo, making the history more obvious. I additionally plan to integrate runvdr-extreme-systemd directly into the vdr package and get rid of the original runvdr, along with the /etc/sysconfig/vdr and /etc/init.d/vdr The problem: this will break the configuration after updating from VDR-1.6.x. If I don't find an easy way to convert /etc/sysconfig/vdr to /etc/runvdr.conf on update, I'll probably just print a warning during update to let people know that the VDR configuration needs manual review. I'll add a README.SUSE which will explain how to move from the old config to the new one. Another option would be to just call the new package "vdr2" and make it conflict with vdr, so that it is not silently installed as an update and people immediately notice that they need to do something. We could also copy the old packages to vdr:legacy or such, for people who rather use the old version (if you don't have HD capable hardware, vdr 1.6 might be "good enough") Any ideas? People who want to suggest "create a sophisticated update process that makes sure that the update does work and the config is converted" are welcome to take over VDR maintainership and do that. I personally have planned to do this for a very long time now (even when VDR-2.0 was still 1.7.xx) and finally realised that I'll never have enough time to do this. That's why I'm now opting for the above approach, which will be less work (and which will make use of the work that Marcel and Hans-Peter have already done, thanks for that). Best regards, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 5

[opensuse-factory] manpage for 'lvcreate' -- does factory have info for thinpools?
by Linda Walsh 04 Apr '14

04 Apr '14

The utility 'lvs' has [--alloc AllocationPolicy] [--thinpool ThinPoolLogicalVolume{Name|Path}] [--poolmetadatasize Size[bBsSkKmMgG]] That don't seem to be in the manpage in 13.1... Is this fixed in factory? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 5

[opensuse-factory] Mesa for Tumbleweed
by Thomas Langkamp 03 Apr '14

03 Apr '14

Would it be possible to have Meas 10.x and LLVM 3.4 in Tumbleweed? That would be really good for radeonSI users (OpenGL 3.1 instead 2.1) and is would be much appreciated since openSUSE 13.2 is delayed... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 9

[opensuse-factory] Inclusion of Pitivi 0.92 and its dependencies to Tumbleweed
by Yonsung Lee 02 Apr '14

02 Apr '14

Hi all (first time mailing here, so pardon me if mistakes are made), The current version of Pitivi available for OpenSUSE:Stable is 0.15. It's buggy and limited, and was released in 2011. Since then, Pitivi has switched to using Gstreamer Editing Services (GES) as its platform, and its performance and stability has improved *exponentially*. The current stable release (0.92) is much more usable than 0.15. As far as I remember, there are two dependencies that need to be added as well, gstreamer-editing-services and GNonLin 1.1.90. Links to factory: https://build.opensuse.org/package/show?project=openSUSE% 3AFactory&package=pitivi https://build.opensuse.org/package/show?project=openSUSE% 3AFactory&package=gstreamer-editing-services https://build.opensuse.org/package/show?project=openSUSE% 3AFactory&package=gnonlin It would be great if this could be added to Tumbleweed, as we all know Linux users are in need of an intuitive yet versatile video editor. Thanks in advance, Y.L. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 6

Re: [opensuse-factory] Base:System util-linux, regarding sr 226509
by Stanislav Brabec 02 Apr '14

02 Apr '14

Ruediger Meier wrote: > On Friday 21 March 2014, Stanislav Brabec wrote: > > Ruediger Meier wrote: > > > Hi, > > > > > > The ChangeLog is almost useless since none of the referenced bug > > > reports is readable for non-suse people. > > > > These changelogs were taken from the original changelog. Many of > > openSUSE changelogs refer to bugs that are not accessible. In ideal > > case, people working on SLES fix would post the same patch to > > openSUSE, and make a public clone of the bug report. It did not > > happened, and a review found these patches, where the patch was not > > posted to Factory nor upstream. > > > > > At least one of the added patches ("umount-avoid-readlink.patch") > > > has no effect because it patches a deprecated and unused subdir > > > which will be removed in next release anyway. > > > > Yes, it is deliberate. The patch was created for SLE11 and affects > > the code, which is now deprecated and not used. I did not want to > > lose this patch and save it for upstreaming. > > Upstream has already removed the whole code. If upstream dropped "mount-deprecated" completely, then the patch as is is obsolete, and can be dropped now (or in the next version that will have no "mount-deprecated" code). > > Collecting upstream-able patches will take some time. Hopefully these > > patches will disappear from the Factory then. > > I'd like to help to get useful patches upstream. But it's hard if I'm > not allowed to know anything about the fixed issues. Well, there is also a lot of openSUSE patches, that need to check its universal validity. Regarding the SLES11 patches: sfdisk-warn-about-2TB-limit.patch: The msdos partition table is suppose to address up to 2 TB LUNs. Sfdisk didn't stop (or warning) the user about this limitation and went ahead created partition beyond 2 TB. After the reboot, the device node for the partition starting above 2TB was not created. Fix is impossible, but sfdisk should warn about it. The same bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324525 util-linux-ng-2.16-squashfs3-detect.patch: Detection of squashfs3 filesystem was requested. util-linux-ng-2.19.1-barrier_documentation.patch: The description of the 'barrier' mount option was request. Patch was written by Jan Kára. He wrote in the bug, that he sent the patch to the upstream as well. Maybe it was lost. util-linux-update-default-commit-interval.patch: Customer pointed out with the inclusion of the linux-2.6.29-jbd-longer-commit-interval.patch, changing "kjournald starting. Commit interval 15 seconds" from the long standing default "5 seconds", the "mount" man pages are no longer correct. Obsoleting of uuid-runtime: That package existed between SLE11 SP1 and SLE11 SP3 and probably sometimes in past. I failed to track the package origin, but it is safe to keep Obsoletes in the spec file. umount-avoid-readlink.patch: The problem existed (exists?) on NFS (reproduced on SLE11 SP2 on s390x, but probably was (is?) reproducible on all platforms): 1) sudo mount -t nfs4 -o sec=sys,intr,noac,nordirplus machine:/dir,binary /mnt 2) stop/reconfig NFS server 3) sudo umount -f /mnt umount2: Stale NFS file handle umount.nfs4: /mnt: Stale NFS file handle umount2: Stale NFS file handle umount.nfs4: /mnt: Stale NFS file handle sudo umount /mnt umount.nfs4: /mnt: Stale NFS file handle umount.nfs4: /mnt: Stale NFS file handle File conflict: Package s390-32 contains files s390 and s390x conflicting with util-linux and breaks installation on System Z. uname26: There was a request to support uname26 in PAM (it already is) and have a simple to use uname26 binary. > > > Please somebody have a look at the last changelog and either make > > > the bug reports world-readable or fix the changlog to explain the > > > purpose of these patches: > > > > SLES bug reports that contain sensitive customer data cannot be > > opened for public. > > Have you really checked all the bug reports and they all contain > sensitive data? Well, if the bug is reported against SLES, there is no way to make it public in Bugzilla. The only way is making an openSUSE clone. Most of SLE bugs contain commercial support information, machine configurations and similar sensitive data. > > Most of these patches are self descriptive. Well, this one is > > probably not true for umount-avoid-readlink.patch: > > > > It's purpose is avoiding a readlink() failure when umount'ing stale > > NFS volumes. > > But today your patch only changes unused code. If this is still an issue > in the new code then your patch will not fix it. Volunteer reviewers > (like me) cannot really check if there is still an issue or not. Also > I'd like to check whether this patch would be good for Evergreen 11.4. I know. The code of umount is completely rewritten, and I was not able to determine, whether it is still needed. I plan to do test of these problems and then either port them or drop. > > > * lscpu: improve hypervisor detection (puzel(a)novell.com, > > > fate#310255) > > This patch for example breaks a test in the test suite. None of us can > read the discussion about this new feature. non-SLE people had no > chance to say their opinion about it. Patch was written by Petr Uzel. There was requested detection of all Hypervisors on x86_64, System Z and Power in lscpu and detect virtual graphic adapters. Adding him to Cc. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 8

[opensuse-factory] wow
by Peter Czanik 02 Apr '14

02 Apr '14

Hello, I just did a fresh installation of factory. Network manager in KDE displays an error, but networking seems to work fine. $SUBJECT is "wow" because I don't recall openSUSE booting ever so fast! What was changed? I did not check with a timer, but it seems to be faster now than other distros, while earlier openSUSE was among the slow starters. Not that it matters on a machine I turn on only once a day, but still :-) Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

11 25

[opensuse-factory] libwrap still broken over 2 years later...
by Linda Walsh 01 Apr '14

01 Apr '14

Just rebooted (it had been 60 days since last reboot), and it picked up the new tcpd/libwrap0 files from 13.1 (am pretty sure it's not fixed in factory, given it hasn't been fixed in over 2 years)... This is still a problem: http://lists.opensuse.org/opensuse/2011-10/msg00351.html Thought it was reported as I have a patch file... making sure it is reported here: https://bugzilla.novell.com/show_bug.cgi?id=861989 (had problems w/attachment, so am including it here as well..).

4 4

[opensuse-factory] Security issue: Proposal to revert to '/' on sep. part. from /usr,/home,/tmp,/var, etc
by Linda Walsh 01 Apr '14

01 Apr '14

WTF? Am I crazy? Following is a chain of logical events that have happened and are likely to happen that will cause even more security patches to compensate for the merge of '/' with other partitions (include /usr/share -- which was supposed to be independently sharable, yet the keyboard services needs it to load 'locales'). The conclusion is at the end, if you are one of those who are impaired with the TLDR disease. Well, yeah, and? The new setup is being used as a justification for a need for a new and ill designed security feature: "protected_hardlinks" that disables standard, legacy linking ability. In 13.1, this feature is turned on by default. That causes side effects, like not being able to copy a R/O source-tree with "cp -al", into a 2nd copy of symlinked dirs w/hard-linked file objects. To me, that was a basic source control mechanism -- anything that was the same between the two (or 20 trees) shared the same file and was read-only as someone other than the owner of the original source tree (often root). Local mods in source files could be made in your source tree but they wouldn't propagate to to the source copy. Now, such a setup is impossible in the default suse config unless a user has access to root and/or is willing to risk overwriting the original source. The main justification for protected_hardlinks was to protect users from linking to files that used to be on *separate* file systems (/etc/{shadow,group,passwd}) to use for some further exploit -- claim a lost of files and a need for their homedir to be restored via some util that writes to a hardlinked file w/root privs, for example. But now, along comes the protected_hardlinks feature which doesn't do the same job. It allows linking, only, to _regular files_ that you have write access to. Logically, to get around the inability to link w/o write access, one might think to make sure the copying user is in the same group as the target files and use group write access. That causes 2 problems: 1) it doesn't solve the original requirement of keeping the original source tree read-only to other users (i.e. if the users have write access through the group, they can overwrite the original, but worse, 2) protected_hardlinks was implemented to inconsistently allow hardlinking to objects in in the source tree. While it used to be the case that one could hardlink to any readable non-directory on the same device, protected_hardlinks changes that to allow hard-linking not just to "writeable" files, but only *regular files*. This means for example, that the kernel source tree can no longer be copied by anyone other than the tree owner due to symlink usage in the kernel (that were previously hardlinked to): > find . -type l|xargs ls -dgGl|cut -c30-999 ./arch/arm/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings ./arch/metag/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings ./arch/microblaze/boot/dts/system.dts -> ../../platform/generic/system.dts ./arch/mips/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings ./arch/powerpc/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings Of less commonality, but also affected were hardlinks to named pipes, sockets, -- any other file system object -- except for dirs which, on linux, have pretty much always been disallowed. Notably, now, we have a broken workaround to re-create security lost by previously having a separate root (broken in that it only partly works for some objects), but it's already being discussed how utility (applications will have to follow) progs will deal with making copies when "cp -al" is used -- i.e. it is likely that linux will fall back to DOS-level functionality where copies are made for any file object that doesn't support linking. This has a further security impact: any ACL's or security labels on a readable file will be stripped unless the copying user has the ability to recreate them (often not true if the source tree was designed to be read-only to the copier). I found that to already by a problem when 'mv'ing files -- a few samba versions mistakenly put NT-acl's in the 'security' or 'system' namespace, when such ACL's are not native acls, but a user-app (samba) level data-blob. That issue was raised with the samba team, and it appears it will be addressed, though no official statement was made about the security hole (a Windows user who has login access to the domain will be able to, by default, strip the file of it's NT-ACL just by moving it to another partition or by copying it (whether they intend this or not -- it's not a good side-effect). ========================= **TLDR: In short, the joining of the partitions has already caused broken security workarounds to go into the kernel (that still need to be fixed), and is in the process of requiring system utils and applications to invent workarounds for the security implications -- that themselves cause their own set of security issues that will need more patches, and likely cause more rounds. I.e. this is a case of a bad decision causing a chain of worsening and growing side effects. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 7

[opensuse-factory] Releases going forward
by Robert Schweikert 31 Mar '14

31 Mar '14

Hi, Releases going forward, or, how do we release without full time paid worker bees? With all the discussion toward the end of last year I suppose that today's e-mail "Timeline and roadmap V2" [1] finally shed light on the inevitable conclusion, the openSUSE team (@SUSE) will spend more time on other stuff and less time, if any, on turning the release crank. This is the team's prerogative just like everyone is free to work on the project, or not, in areas of interest to them. We can argue whether the way this is coming about is giving the project the best chance to succeed or whether the transition is being put worth in a nice and friendly way, but I think we should not go down that path. Thanks! to the openSUSE Team for the hard work they have put forth in the past to turning the release crank, it is much appreciated. I think the time has come to move forward and deal with the new situation. As of right now we still have a release cycle of 8 month. That would put us into May for openSUSE 13.2. This brings about two questions: - Given the current situation can we meet a May release date? - Do we skip the May release and move to a yearly cycle and release 13.2 in November of 2014? During last year's discussions there were a number of people favoring a yearly release cycle. We have to make a decision, - stick to 8 month or move to 12 month? Voice your opinion but stick to the point and please be concise. For simplicity lets just assume that there will be no full time paid help to turn the release crank and that the work is all on those that are not part of the openSUSE Team. Under any circumstances I'd say our first go around will be a bit rough around the edges and that's OK, we have to learn. What do I have to offer? After all stuff will not get done by me sending an e-mail into the world. I offer to take on part of the role of "Release Manager". I will not be able to do all of it and I have a new definition for the role (see below.) Stephan did way more and was always the tireless worker that brought everything together. No one that does not work on openSUSE full time can obviously fulfill that role, thus we have to split things up. I figure there are about 60 to 70 hours worth of work per week that we have to distribute. I'll define "Release Manager" as: The person or group that runs after people, keeps an eye on the schedule and tries to herd the cats to get the stuff fixed that is broken. I am willing to take part of that role, and with this mail hopefully be a rallying point to put openSUSE releases on a bit more of a solid footing than where we are today, after [1]. If we go this route it implies that everyone that has stuff in Factory, what will become the next release, nothing there changes, has more responsibility in helping out than they do today. We no longer have people that can fix everything and get to spend all their time on the distribution and integration of stuff. Every maintainer has more responsibility. So where do we go from here? Do we bootstrap an effort to get a release out the door without openSUSE @SUSE or do we drift along in the uncertainty of "maybe we know something in August"? I am happy to be a rallying point and fulfill part of the role of "Release Manager" as outlined above. Maintainers/Packagers be heard, speak up, but lets not drift into rat holes, the situation is actually quite simple. Later, Robert [1] http://lists.opensuse.org/opensuse-factory/2014-01/msg00350.html -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

30 62

[opensuse-factory] kGraft @ 13.2 ?
by Matwey V. Kornilov 31 Mar '14

31 Mar '14

Hi, Will kGraft be supported for upcoming openSUSE release? Will the patches preparation be integrated into OBS? AFAIU, it is needed to produce special patch-module to load it, in order to fix something, so actual patch has to be wrapped around some kGraft-specific code to produce such a module. -- 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] Question about libzypp
by denisart benjamin2 31 Mar '14

31 Mar '14

Hello everyone ! Does somebody know why libzypp doesn't have anything like "yumdb set reason dep $PACKAGE" or "aptitude markauto $PACKAGE" ? Thanks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 3

[opensuse-factory] Status: Distribution
by Stephan Kulow 29 Mar '14

29 Mar '14

Hi, On Feb 24 I announced that factory reached 7000 packages, today is Mar 25 and I can tell you, we have 7100. And I'm hopeful that we can reach a more important milestone this week: having openqa.opensuse.org updated to new hardware and software, so you can finally see what I can see. When that's done, my plan is to tackle a revised Factory-Tested repo that will be the "new" factory. But the details are still to be checked, our priority is public openQA at the moment. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 4

[opensuse-factory] RFT: gnome-bluetooth-applet for Non-GNOME and Non-KDE desktops.
by Stefan Seyfried 28 Mar '14

28 Mar '14

Hi all, while checking for some graphical tool to configure bluetooth on desktops other than GNOME and KDE (I personally am very happy with command line bluetoothctl, but I see the need for something more colorful ;-), I came across two projects: * xfce4-bluetooth https://github.com/ncopa/xfce-bluetooth * gnome-bluetooth-applet https://github.com/City-busz/gnome-bluetooth-applet The first is just in its initial stage (means: you get an Icon and some dialogs, but cannot do anything useful with it, yet). It had a short burst of development action after it was started but now is silent without action for over 6 Months. The second is more useful: it is a fork of the gnome-bluetooth applet code from pre-GNOME-3.8, and only the applet code, apparently slightly forward ported to work with current gnome-bluetooth. This has some consequences: 1) it uses the well-maintained gnome-bluetooth stack (libgnome-bluetooth-applet.so.0, libgnome-bluetooth.so.12) for handling the low-level stuff (communication with bluez etc), the applet just displays an interface to gnome-bluetooth. In GNOME this is done by gnome-shell. 2) it needs gnome-bluetooth and friends, probably dragging in quite a big part of GNOME. I personally don't mind 2), since I have installed most of it anyway and disk is cheap, if it saves me from implementing all the dirty low-level stuff (most of which I cannot really test anyway). So what I would want to do is propose gnome-bluetooth-applet for inclusion in Factory and later maybe in the XFCE and other non-mainstream-desktop patterns, so that we can make bluetooth usable for more people out of the box. Right now I have packaged it in home:seife:bluetooth, it builds for 13.1 and Factory. If people interested in using bluetooth outside KDE or GNOME would test it and give feedback, then I can decide if it is worth polishing and getting ready for inclusion in openSUSE proper. add obs://home:seife:bluetooth to your repositories and try it! :-) Best regards, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 26

[opensuse-factory] 13.2M0 fails to boot
by Jogchum Reitsma 28 Mar '14

28 Mar '14

Hi, Iinstalled 13.3M0 on my "experiment disk" in my production system. One thing I changed in the suggested setup was that I placed the boot code on the root partition on that disk, instead of in the MBR of my first disk (which is part of the production disk set, so I don't want to fool around with that). Intallation went without a glitch, but it won't boot, complaining that /dev/root cannot be found. I am presented with the choice to seek it on /dev/dsf2 (the root partition of the experiment disk), but refuses to respond to the keyboard (except for Ctrl-Alt-Del, which leads to a reboot...). So I'm stuck here. Any thoughts? regards, Jogchum -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 16

[opensuse-factory] 13.2 M0: No DNS-settings via DHCP?
by Johannes Kastl 28 Mar '14

28 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, just installed the milestone in a qemu-kvm machine and started playing around. One thing I noticed: In the DNS and hostname settings in yast, "modify DNS settings" is always set to "Only Manualy". I do get an IP via DNS, but not nameservers. /etc/resolv.conf is empty (apart from the comments). The hostname seems to be set, although the yast dialogue shows "linux" as hostname. Regards, Johannes P.S.: Is there a 'known bugs in milestone 0' document available somewhere? - -- `Don't, Ginny, we'll send you loads of owls.´ `We'll send you a Hogwarts toilet seat.´ `George!´ `Only joking, Mum.´ (Harry Potter and the Philosopher's Stone) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlM0WvMACgkQzi3gQ/xETbK7AwCeIgnRyJd8Jpkgfz7XwTi9cYQs hn0An2kiRqLxgLYHSRs2NZ5BZUHb7QZB =yEbX -----END PGP SIGNATURE----- -- 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] legacy actions in /usr/sbin/service
by Ludwig Nussel 28 Mar '14

28 Mar '14

Hi, Init scripts sometimes implement additional actions besides the usual start/stop/status etc. For systemd service files that extra feature doesn't exist. It's still convenient to have for some services though. Therefore /usr/sbin/service now implement "legacy actions" like Fedora. Suppose your previous init script "foo" had an action "frob". Now the service file is called "foo.service" and you want to still support that action. In Factory you can now create a script /usr/lib/initscripts/legacy-actions/foo/frob that implements the feature you need. Obviously the action is only available when calling the service via /usr/sbin/service, ie "service foo frob" or "rcfoo frob". cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- 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] Tumbleweed: virt-manager-common-1.0.1-5.1.noarch requires grub2-x86_64-xen ???
by Patrick Shanahan 28 Mar '14

28 Mar '14

virt-manager-common-1.0.1-5.1.noarch wants grub2-x86_64-xen which doesn't appear to exist in openSUSE ??? or hasn't built since yesterday morning ? software.opensuse.org/search for grub2-x86_64-xen provides no package/answer. bug report? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- 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] 13.2 Milestone0: German keyboard layout not set correctly
by Johannes Kastl 27 Mar '14

27 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi list, after installing the milestone in a vm I noticed, that although the keyboard is set to German in Yast, I still have a en-US layout when logging in as root. I have not tested as non-root, but I can, if it helps... Regards, Johannes - -- Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. (Terry Pratchett: The Truth) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlM0Zb4ACgkQzi3gQ/xETbJrcgCdF/OVmOMuNRu973aftjigXOIe qYQAmgODQFCKTuMA/SXbczEhFXcw40Cr =Oq6Y -----END PGP SIGNATURE----- -- 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] YaST2 crashes in 13.2 m0
by Graham P Davis 27 Mar '14

27 Mar '14

Installed 13.2 m0 yesterday and found YaST2 failed in "Software Management" module after selecting packages to install and continuing. Ran from console when logged on as "root" and got the following messages: linux:~ # yast2 "Qt Warning - invalid keysym: dead_actute" libGL error: dlopen /usr/lib64/dri/updates/nouveau_dri.so failed (/usr/lib64/dri/updates/nouveau_dri.so: cannot open shared object file: No such file or directory) Run command: /sbin/yast2 sw_single & libGL error: dlopen /usr/lib64/dri/updates/nouveau_dri.so failed (/usr/lib64/dri/updates/nouveau_dri.so: cannot open shared object file: No such file or directory) YaST got signal 11 at YCP file /usr/share/YaST2/modules/SlideShow.rb:385 /sbin/yast2: line 429: 4522 Segmentation fault $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS linux:~ # When I tried this as a normal user, I could not get any messages. I've installed debuginfo modules for YaST but these did nothing apparently. Just tried again and the problem has worsened in that the crash occurs as soon as "Software Management" is selected. linux:~ # yast2 "Qt Warning - invalid keysym: dead_actute" libGL error: dlopen /usr/lib64/dri/updates/nouveau_dri.so failed (/usr/lib64/dri/updates/nouveau_dri.so: cannot open shared object file: No such file or directory) Run command: /sbin/yast2 sw_single & libGL error: dlopen /usr/lib64/dri/updates/nouveau_dri.so failed (/usr/lib64/dri/updates/nouveau_dri.so: cannot open shared object file: No such file or directory) YaST got signal 11 at YCP file /usr/share/YaST2/modules/PackageCallbacks.rb:2159 /sbin/yast2: line 429: 5103 Segmentation fault $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS linux:~ # -- Graham Davis, Bracknell, Berks. openSUSE 13.1 (64-bit); KDE 4.12.3; AMD Phenom II X2 550 Processor; Kernel: 3.11.10; Video: nVidia GeForce 210 (using nVidia driver); Sound: ATI SBx00 Azalia (Intel HDA); Wireless: BCM4306 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 8

[opensuse-factory] graphics / SmartDeblur → Factory Submit Request
by Dmitriy Perlow 26 Mar '14

26 Mar '14

Hi to all! > SmartDeblur is a user friendly and useful tool for restoring blurry and > defocused images. Blurry images are universal in our life. There are > many causes of that: camera shakes, defocussing, artificial blur via > photo editors like Photoshop or Gimp. Many people think that blurring is > an irreversible operation and the information in this case is lost for > good. But it is not quite true - now you can restore your blurry images > using SmartDeblur. New release features a blind deblurring module which > can automatically identify and remove complicated blur patterns in an > image. Just load your image and click on the "Analyze Blur" button - the > rest will be done automatically! Official site: http://smartdeblur.net Github page: https://github.com/Y-Vladimir/SmartDeblur Author page: http://yuzhikov.com/projects.html Restoration of defocused and blurred images (part 1) - theory: http://yuzhikov.com/articles/BlurredImagesRestoration1.htm Restoration of defocused and blurred images (part 2) - practice: http://yuzhikov.com/articles/BlurredImagesRestoration2.htm But only non-latest app versions are open sourced under GPL3, the newest one can only be bought and only for MS Windows or Apple Mac OS. By default the app promotes commercial edition at startup, but I've patched it: https://build.opensuse.org/package/view_file/graphics/SmartDeblur/SmartDebl… (no Linux version so no sense to show the ad) ]:-> Let’s get ready to rumble! ;) -- Best regards, Dmitriy DA(P).DarkneSS Perlow @ Linux x64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 4

[opensuse-factory] New packages for pandoc document processor
by Peter Trommler 26 Mar '14

26 Mar '14

Hi, This email is to announce a number of packages I am planning to submit to Factory as part of pandoc, which was requested in FATE #312777 (https://features.opensuse.org/312777). The packages are being developed in devel:languages:haskell. Scott Bahling has kindly agreed to share maintenance of the 30 packages in total. So here is my share: ghc-aeson ghc-base-unicode-symbols ghc-base64-bytestring ghc-blaze-builder ghc-blaze-html ghc-blaze-markup ghc-digest ghc-dlist ghc-extensible-exceptions ghc-hslua ghc-pcre-light ghc-tagsoup ghc-temporary ghc-zip-archive highlighting-kate I will maintain these packages for openSUSE with all the associated duties. Cheers, Peter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 2

[opensuse-factory] Drop of yast2-iscsi-server
by Josef Reidinger 25 Mar '14

25 Mar '14

Hi, because iscsitarget and its respective part is dropped, we ( as a yast team ) also going to drop yast2-iscsi-server. Now preferred way for iscsi server is iscsi lio server for which there is new module in factory yast2-iscsi-lio-server. If there is someone who want to take maintain of all dropped parts, then please contact us and we can help him. Josef -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

Re: [opensuse-factory] YaST2 crashes in 13.2 m0
by Graham P Davis 24 Mar '14

24 Mar '14

On Mon, 24 Mar 2014 10:22:46 +0100 Richard Brown <RBrownCCB(a)opensuse.org> wrote: > On 21 Mar 2014 10:03, "Graham P Davis" <hacker(a)scarlet-jade.com> > wrote: > > > > Installed 13.2 m0 yesterday and found YaST2 failed in "Software > > Management" module after selecting packages to install and > > continuing. Ran from console when logged on as "root" and got the > > following messages: > > > > linux:~ # yast2 > > "Qt Warning - invalid keysym: dead_actute" > > libGL error: dlopen /usr/lib64/dri/updates/nouveau_dri.so failed > (/usr/lib64/dri/updates/nouveau_dri.so: cannot open shared object > file: No such file or directory) > > Run command: /sbin/yast2 sw_single & > > libGL error: dlopen /usr/lib64/dri/updates/nouveau_dri.so failed > (/usr/lib64/dri/updates/nouveau_dri.so: cannot open shared object > file: No such file or directory) > > YaST got signal 11 at YCP > > file /usr/share/YaST2/modules/SlideShow.rb:385 /sbin/yast2: line > > 429: 4522 Segmentation fault $ybindir/y2base > $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS > > linux:~ # > > > > When I tried this as a normal user, I could not get any messages. > > > > I've installed debuginfo modules for YaST but these did nothing > > apparently. > > > > Just tried again and the problem has worsened in that the crash > > occurs as soon as "Software Management" is selected. > > > > linux:~ # yast2 > > "Qt Warning - invalid keysym: dead_actute" > > libGL error: dlopen /usr/lib64/dri/updates/nouveau_dri.so failed > (/usr/lib64/dri/updates/nouveau_dri.so: cannot open shared object > file: No such file or directory) > > Run command: /sbin/yast2 sw_single & > > libGL error: dlopen /usr/lib64/dri/updates/nouveau_dri.so failed > (/usr/lib64/dri/updates/nouveau_dri.so: cannot open shared object > file: No such file or directory) > > YaST got signal 11 at YCP file > /usr/share/YaST2/modules/PackageCallbacks.rb:2159 > > /sbin/yast2: line 429: 5103 Segmentation fault $ybindir/y2base > $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS > > linux:~ # > > > > > > Hi there, > > I cant reproduce this on my M0 installation, but I'm using GNOME - so > I suspect you might be able to run yast2 --gtk to workaround the > issue for now. > > Hope this helps, > Thanks, Richard, but the problem has been fixed by removing libproxy1-config-kde4 and then tabooing it. If it is not tabooed, YaST insists on re-installing it (as, by the way, it also does for Apper and Packagekit). See https://bugzilla.novell.com/show_bug.cgi?id=866692 -- Graham Davis, Bracknell, Berks. openSUSE 13.2-m0 (64-bit); KDE 4.12.2; AMD Phenom II X2 550 Processor; Kernel: 3.14.0-rc5; Video: nVidia GeForce 210 (using nouveau driver); Sound: ATI SBx00 Azalia (Intel HDA) -- 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] Getting multiple monitors to work on openSUSE
by Sankar P 23 Mar '14

23 Mar '14

Hi, I have a thinkpad T430 with nvidia NVS 5400 M graphics card. I have two HP monitors, where one is connected via the VGA port and another via the DVI port in the docking station. However, the opensource drivers recognize only the VGA port. The monitor on the DVI port is not even recognized. I want to use only the two desktop monitors side by side as a single big monitor and do not want the laptop monitor to be used when the laptop is in the docking station. I could get this setup working in Windows without any effort. But in openSUSE 13.1 with the default opensource driver it failed. With the proprietary nvidia driver from the nvidia repository in the openSUSE repository, I could get both the monitors detected. But the driver is very buggy. It freezes the entire display randomly and I figured that it was doing so whenever it had to change the display brightness for some reason. Also, another big problem is, it fails to boot everytime and hangs the machine after the "setting up Plymouth screen" (or some such message) in the bootscreen. If I boot via the "Integerated graphics" setting in the bios to recover from this cpu freeze on boot, I could realize that it was hanging during the "setting up acpi display brightness" thing again. I am not too sure if reporting a bug on the nvidia driver will make any progress at all, considering that even Linus has not had much progress with nvidia. Also I am not even sure where to report the bug for the nvidia proprietary driver. Now, is it possible to get the opensource driver to get the multiple monitor support working somehow ? I do not mind installing developmental patches or custom kernels if needed. Any help ? Thanks. P.S: Re-posting here after I got no response in the opensuse-xorg mailing list. -- Sankar P http://psankar.blogspot.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 4

[opensuse-factory] Virt-Manager 1.0
by Christian Grassi 22 Mar '14

22 Mar '14

Hi all, Is there any plan to have virt-manager 1.0 in Tumbleweed. Thanks Christian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 15

[opensuse-factory] Include lxc in Tumbleweed
by Johannes Kastl 22 Mar '14

22 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone (part 2), any thoughts against including lxc in Tumbleweed? The virtualization-repo contains a package for the latest release 1.0, and it should be in factory, afaik. Regards, Johannes - -- `Oh, you may not think I'm pretty, But don't judge on what you see, I'll eat myself if you can find a smarter hat than me.´ (The Sorting Hat in Harry Potter I) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlMh+u4ACgkQzi3gQ/xETbJLFwCglmlJAgUfnQm4fQtSeaaNEGWW SdIAoIONdr2TOzLaByRnXUMoS7RQdBWf =bicg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 4

[opensuse-factory] Base:System util-linux, regarding sr 226509
by Ruediger Meier 21 Mar '14

21 Mar '14

Hi, The ChangeLog is almost useless since none of the referenced bug reports is readable for non-suse people. At least one of the added patches ("umount-avoid-readlink.patch") has no effect because it patches a deprecated and unused subdir which will be removed in next release anyway. Please somebody have a look at the last changelog and either make the bug reports world-readable or fix the changlog to explain the purpose of these patches: ------------ Mon Mar 17 22:36:58 CET 2014 - sbrabec(a)suse.cz - Merge fixes and features from SLE11 (bnc#831868): * Detect squashfs version <= 3 as squashfs3 and version >= 4 as squashfs. (mszeredi(a)suse.cz, util-linux-ng-2.16-squashfs3-detect.patch, bnc#666893) * add sfdisk-warn-about-2TB-limit.patch (puzel(a)novell.com, bnc#495657) * Document barrier option in mount.8 (jack(a)suse.cz, hvogel(a)suse.de, util-linux-ng-2.19.1-barrier_documentation.patch, bnc#489740) * lscpu: improve hypervisor detection (puzel(a)novell.com, fate#310255) - util-linux-lscpu-improve-hypervisor-detection.patch * umount: avoid calling readlink on mountpoints if not necessary - add: umount-avoid-readlink.patch (puzel(a)suse.com, bnc#794529) * fix file conflict between util-linux and s390-32 (puzel(a)suse.com, bnc#805684) * util-linux-update-default-commit-interval.patch: mount(8): update default commit interval (puzel(a)suse.com, bnc#809480) * Obsolete no more packaged uuid-runtime. - Add uname26 (util-linux-setarch-uname26.patch, FATE#313476). ---------------- cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 4

[opensuse-factory] Proposal or Request to remove openSUSE13_1_LOCAL.exe from the install media.
by Carlos E. R. 21 Mar '14

21 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The installation DVD contains these files: openSUSE13_1_LOCAL.exe openSUSE13_1_NET.exe autorun.inf People popping the DVD on a Windows machine will run that file, automatically, and try to install openSUSE that way. It does not work: ever, AFAIK. It is not documented anywhere. No mention of it in the startup guide or reference book, or I have not seen it. People now and then come to the forums, disappointed that openSUSE does not work, until we find out that they are trying to install "The Windows Way". Immediately and abruptly we tell them not to use an unsupported, obsolete, method that does not work and nobody knows anything about it. To boot the DVD and use the supported and documented method instead. Proposal: a) · That the procedure is explicitly and clearly documented in our books. · That somebody steps up and support, hand holding as necessary, the newcomers that try this method. · That a method to contact that/those person(s) is clearly published. · That there a readme file about this method is included in the install media. b) · Lacking any of the above (a), the installation .exe files and autorun.inf be completely removed from our install media. (Excuse my harshness if you feel that way. No impoliteness was intended). - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlMsGYAACgkQtTMYHG2NR9V1xgCfSPsXt/SCA3R7EqkgJCPBdmw8 GzYAn0QNeR05gzssPZYoifRpVtzXDYaS =43Wf -----END PGP SIGNATURE-----

2 2

[opensuse-factory] When was it decided to stop supporting remote desktops?
by Linda Walsh 20 Mar '14

20 Mar '14

It seems that's what has happened. When the dri drivers went into the X server, the removed the Xgl (or was it Xglx) extension that allowed OpenGL to be encapsulated in X. This meant you could have a server with lots of resources to do computations that would use a remote computer with a high end graphics card on any platform that supported X (BSD, MacOS, Windows (xp to win7) as well as desktop linux clients that don't have the same resources as a server. FWIW, the server wasn't built with available power supplies to even begin to support high end graphics cards these days. It seems also that this is the reason why XDMCP no longer works -- it was another remote desktop facility that would have needed the Xgl to transport most of today's desktop managers that use graphics acceleration to enable faster desktop respond with fancier effects. OpenGL *used* to work remotely on openSuse. Not anymore -- it seems that no form of remote testing or forwarding a remote desktop has been done for the past few cycles. I am biased in that I wanted to be able to use such occasionally -- maybe more so with an upgraded network. Was it actually planned, or did RedHat just kill it and other vendors followed suit because they went with the dri solution? The wayland support also doesn't seem to have an X-compat solution for 3D either. I'm not sure how possible or easy it would be, but it might be possible to get a degraded performance with a virtualGL solution that was designed to send the rendering commands to a 3rd computer that just did rendering and display the result to the client using the equivalent of jpeg/mpeg compression over slower networks, but possibly uncompressed over faster networks coming down the line. If the user has a 1Gb ethernet -- not unreasonable, they would have a max of about a max theoretical around 0.12GB which is about 7 frames/second if you try to send full screens, it would be hard to compress and uncompress that in SW to make it faster. But if you are just sending the rendering commands, it's like the difference between SVG and bitmapped graphics. The latter is 100's to 1000's times larger. Some of the largest SVG's I've seen have still been under 1MB, vs. bitmapped tiff's ... I've seen a few too many 4+GB that take a long time to read or write even over 1Gb. I'm guessing this wasn't intentional (??I hope), but that not many people realized what was happening until some time after the fact?? Is breaking remote compatibility with the past 15+ years a good thing? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

11 33

[opensuse-factory] M0 installation proposed xfs for /home
by Robert Munteanu 20 Mar '14

20 Mar '14

Hi, Just installed M0 from DVD. I pretty much kept to the defaults, and I noticed that /home is xfs, not btrfs, although I have other partitions formatter as btrfs. I was under the impression that the default is btrfs for 13.2 [1] Is this intentional? Robert [1]: https://news.opensuse.org/2014/03/19/development-for-13-2-kicks-off/ -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 3

Re: [opensuse-factory] Re: When was it decided to stop supporting remote desktops?
by Carlos E. R. 19 Mar '14

19 Mar '14

On 2014-03-19 18:20, Claudio Freire wrote: > On Tue, Mar 18, 2014 at 8:54 PM, Carlos E. R. wrote: Your post did not reach the list. The reason is that it contains an html part, thus the mail server rejects it. Silently, it seems. You have to configure your mail software to send pure plain text email only, at least to the lists. I'll copy your email back. > > It seems to be doing the rasterization in software on the X server, in > > spite of having more than enough acceleration capabilities, > resulting in > > 8fps or less (couldn't accurately measure). > > Well, that's expected for Nouveau, accel is not complete. > > > How come nouveau has enough acceleration support to run compositing > desktops and even games I believe (haven't tested the more demanding > ones), but not glxgears? > > Does xgl impose some seldom-supported mode of operation? (I can't > imagine that) You could compare how fast it runs locally and how fast remotely. If they are very different, I can only guess that it does not use the same methods in each case. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

2 1

Re: [opensuse-factory] Re: When was it decided to stop supporting remote desktops?
by Carlos E. R. 19 Mar '14

19 Mar '14

On 2014-03-18 20:17, Claudio Freire wrote: > On Tue, Mar 18, 2014 at 9:44 AM, Carlos E. R. <> wrote: Your post did not arrive on the list. Are you sure you are subscribed? > Tried between nVidia-nouveau desktop and headless server (glxgears at > headless server) and it works, if you can call it working. Ah! That's interesting. > It seems to be doing the rasterization in software on the X server, in > spite of having more than enough acceleration capabilities, resulting in > 8fps or less (couldn't accurately measure). Well, that's expected for Nouveau, accel is not complete. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

2 2

[opensuse-factory] osc checks being run by factory-auto ...
by Stefan Dirsch 18 Mar '14

18 Mar '14

Hi Which checks are being run by this "factory-auto" user for openSUSE:Factory? One of the commands appears to be osc service localrun download_files but I'm afraid there are more to come (and fail) when trying to forward a submitrequested package. Is it possible to run these tests during 'osc ci'? BTW, when maintaining a devel project I'm feeling like a fool between accepting and forwarding to factory a valid looking submitrequest and then getting an automatic decline by this factory-auto reviewer of openSUSE:Factory. Can't this be improved, so the submit requester already get the decline? By adding factory-auto as reviewer also for the devel project maybe? Didn't try this yet. Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany -------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -------------------------------------------------------------- -- 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] Status: Distribution
by Stephan Kulow 18 Mar '14

18 Mar '14

Hi, As Factory's Quality is at the moment pretty high and factory-snapshot pretty old, I will release 13.2-Milestone0 this week. Without agenda, but with tons of changes. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 4

[opensuse-factory] oS 13.1 Tumbleweed : LibreOffice crashes on command "File Open"
by ellanios82 16 Mar '14

16 Mar '14

Hello List, - am using XFCE4 with oS 13.1 & Tumbleweed .......... after a recent 'zypper dup' , LibreOffice crashes on command "File Open" ................ - after removing modules from LibreOffice , the culprit appears to be : libreoffice-gnome ................ when libreoffice-gnome is removed, then LibreOffice opens files all right . ................ BUT, the Menu Text is too microscopic for me to be able to read : when using XFCE4 it seems one does need libreoffice-gnome to be able to see a large enough text on Menu Bar, to be readable. ................... [ as a work-around have tried Apache Open Office : this operates OK with nice large Menu Text.] ................. regards -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2