March 2014 - openSUSE Factory - openSUSE Mailing Lists

[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