April 2014 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Installation - no option to change hostname and domain?
by Per Jessen 04 Apr '14

04 Apr '14

I've just realised - yesterday when I installed Factory, I did not see the yast window which would enable me to set the hostname and domain. I think it also enables me to check the "change hostname via DHCP" box. Was this removed intentionally? -- Per Jessen, Zürich (11.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- 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] Re: Mesa for Tumbleweed
by Greg KH 03 Apr '14

03 Apr '14

On Thu, Apr 03, 2014 at 12:12:36PM +0200, langkamp(a)tomblog.de wrote: > > Greg KH <gregkh(a)linux.com> hat am 2. April 2014 um 00:37 geschrieben: > > > > > > On Wed, Apr 02, 2014 at 12:25:04AM +0200, Tobias Klausmann wrote: > > > (snip) > > > >>I'd suggest: > > > >> > > > >>X11:XOrg for Mesa 10.1 > > > >>https://build.opensuse.org/package/show/X11:XOrg/Mesa > > > >$ osc whatdependson openSUSE:13.1 Mesa standard i586 | wc -l > > > > 2003 > > > > > > > >Hah, yeah right, I'm not going to do that, sorry. > > > > > > > >>devel:tools:compiler for llvm 3.4 > > > >>https://build.opensuse.org/package/show/devel:tools:compiler/llvm > > > >I can add this, but is is really used by anyone? > > > > > > It is used to compile parts of/for Mesa, but with you not adding Mesa, it > is > > > more or less pointless to add it. > > > > Ok, I'll go remove it then, thanks. > > > > greg k-h > > Thanks greg for looking into this. I understand that it's too much work? It means I would have to have _all_ of 13.1 in the Tumbleweed repo. Things would be constantly rebuilding. I would have to do a lot more work, and Tumbleweed would be a stand-alone distro image at that point in time. And that's something I've said I was NOT going to do at all every time this has come up in the past. > Maybe the work would seem worthwhile when we know how many people would like > this update. So I opened a request on openFATE: > > https://features.opensuse.org/317173 > > I'll be back when a "reasonable" number of supporters votes this up :) So, it will somehow, because people want this, become more "managable"? That's not how things work, sorry. If you want the latest Mesa, try it in your own private repo and let me know how it goes. Or use the X11:XOrg repo. But given that this is a low-level library, with almost everything depending on it one way or the other, it is going to be tough going, sorry. best of luck, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 6

[opensuse-factory] net+ssh install - running yast just gives me .... yast ?
by Per Jessen 03 Apr '14

03 Apr '14

Previously, when installing over ssh, one only had to type/run 'yast', but this just ends up in the normal YaST menu. It looks like I now need to run 'yast.ssh', is that correct? -- Per Jessen, Zürich (16.5°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- 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] 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] Grub2-EFI and GOP Support for UEFI Systems and 13.2
by Roman Bysh 03 Apr '14

03 Apr '14

Hello List mates, Now that new laptops and motherboards have switched to UEFI it is essential that GOP should be supported. Does any one know that Grub2-EFI for openSUSE 13.2 will add GOP support in the Yast Boot Loader? At the moment most people must add this manually to grub.cfg: insmod efi_gop insmod efi_uga insmod font if loadfont ${prefix}/unicode.pf2 then insmod gfxterm set gfxmode=auto set gfxpayload=keep terminal_output gfxterm fi Any thoughts? Cheers! Roman -------------------------------------------- openSUSE -- Get it! Discover it! Share it! -------------------------------------------- http://linuxcounter.net/ #179293 -- 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] 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

[opensuse-factory] Finding a home for frescobaldi
by Cor Blom 02 Apr '14

02 Apr '14

Hi, For some time I am building frescobaldi[1] in my home project. I would like to move it on the road toward factory and am looking for a suitable devel project. Although the origin lies in KDE it is nowadays a Qt app. I would say multimedia:apps is a good project. If no-one objects or has other ideas, I will prepare a SR. Frescobaldi is a lilypond editor. Thanks, Cor [1] http://www.frescobaldi.org/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

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] Re: Security issue: Proposal to revert to '/' on sep. part. from /usr,/home,/tmp,/var, etc
by Linda Walsh 02 Apr '14

02 Apr '14

Claudio Freire wrote: > Excuse the top posting, on a cell here and it's difficult to bottom post. --- Most gui email programs make it easier to put the most recent stuff at the top -- organizing a timeline from most-recent - older as you go down. Professions that need things organized chronologically tend to use this (medical, legal). Only those who think every detail is important, all the time, for everyone, force bottom posting. > I don't think patching the bare minimum is a good idea in this case... > the more restricting the rules are the less likely the issue remains > exploitable in yet unknown ways. --- Get rid of root entirely -- no exploits... Maybe cut the power as well. Let's take no halfway measures, eh? Um... you are changing system wide security policy. It seems like doing the minimum necessary to disable your exploit(s), is the best idea since every little bit that you change will cause more incompatibility for some program(s) somewhere -- not to mention this breaks posix rules, linux DACL rules, normal unix access restrictions, to name a few. > But maybe restrictions can be relaxed a bit to allow for your use case, > if it is common enough. Can you show an application that is broken by > current rules and that cannot be fixed without changes to the rules? ---- Can you show that your changes break no existing applications? You are proposing the changes but there's been no proof that any compatibility testing was done other than "ubuntu did it". Ubuntu, of course, is known to cater to the technically sophisticated users... who would be likely to use a variety of security scheme, right? Noooop. Ubuntu was designed for those coming from windows -- designed to take away decision points and make things simpler -- which I AGREE with -- but not at the expense of flexibility. I know the features can be turned off, BUT, Some vendors are designing new distro features based on the reduced functionality offered by the increased restrictions -- like putting everything on 1 partition. That used to be considered "bad system administration" and a bad practice for security, maintenance and reliability. It still is, but convenience is trumping everything else. > What you mentioned in the op seems a rather niche use you scripted > yourself and unlikely to be common. ---- Now here's where you are way off, as well as trying to create a self-fulfilling trap. ANY time you script something, it means you have a custom solution -- that by definition is a 'niche use'. If it could be done without a script, it would be a general use case implemented as a feature. Well guess what. There is no script involved. It's a general use case: "cp -al". I've been on many projects where one copy of the source was the pristine, read-only source, and people used links to create a low-space usage copy. This allowed them to create files as 'new files' where they made changes -- everything else was a read-only link enforced by it being a different UID. It may not be a common use case for home users, but for anyone who does development, it's among the simplest and easiest way to create a local "copy" that you can make changes to while keeping the overall disk cost low where you are re-using the original code. > For those cases specifically, there's a sysctl to disable hardlink > protection. ---- Actually, having the hardlink protections disabled are the default case. Opensuse turned them on in /usr/etc/sysctl.conf. Why wouldn't less overwhelming patch work? Specifically w/r/t prot.hardlinks: 1) cannot hard link to a setXID file unless you could create it yourself. 2) cannot link to/from a file in a world-writable sticky-directory. 3) Root privileges will not override sticky bit rules in the case of opening w/write. I.e. if a file already exists in temp owned by another user, root cannot open the file for write in 1 step. They must first either move or remove the sticky file. The latter step (3) makes the system safer than your proposed solution -- since as it is now, root can overwrite (accidently) any user created tmp file in /tmp, possibly destroying valuable work. ========================= Conversely -- specific criticisms of the new implementation: users can hardlink only to writable, regular files. The reasoning is to prevent race conditions and users writing into files expected to be used by root; BUT -- the new restrictions disable hardlinking to other file system objects -- in ALL CASES except where their UID=the object's UID. This disables Group control as well as control by access lists. A great deal of work has gone into making access lists viable -- and work went into making group access viable as well -- yet this disables both of those access methods for controlling hardlinking to writable objects (other than regular files). The irony, is that you can't have setXid objects other than *files* -- and the TOU exploits don't apply, EXCEPT to files... (i.e. they don't apply to hardlinking to symlinks, as you can't rewrite the symlink, they don't apply to other objects either -- named pipes? sockets? semaphores? None of those suffer from the TOU exploits -- yet they were all disabled unilaterally -- and don't even work when you have write access to those objects. ???? That doesn't make sense. If the idea was to protect against TOU problems, why disable linkability to other objects (besides files)? > If you can show a more widespread use case that is similarly affected, > that will encourage kernel developers to come up with less restrictive rules ---- The onus should be on those proposing the wide-ranging and incompatible new rules to prove why they are needed to the extent implemented. If no proof is needed, then just eliminate root, or pull the plug -- the former is practical with FLASK/SeLinux. But the problem is the bigger the change, the more things you break -- which is why I argue for the minimal change necessary. If you want a maximal solution, SELinux is already available. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0