openSUSE Factory December 2019

factory@lists.opensuse.org

61 participants
67 discussions

[opensuse-factory] Can we assume that /bin/sh is bash?

by Martin Wilck

Hi Jan, all, I'd like to carry our OBS dicussion to a wider audience (https://build.opensuse.org/request/show/672510). The question is whether we can assume that "/bin/sh" links to bash, in particular whether rpm scriptlets without explicit -p interpreter can be assumed to interpreted by bash. I'm aware that, in principle, /bin/sh is supposed to be the Bourne shell on Unix systems. But as a matter of fact, on current openSUSE, it is not. Unless it's tampered with, /bin/sh is a symlink to /bin/bash. bash is not started in full POSIX mode if invoked as /bin/sh, and even if it's in POSIX mode, it supports some extensions over the POSIX shell spec (e.g. the [[ ]] construct), which makes it behave differently than another shell not supporting [[ ]] would (*). Problably there are more differences, I can't claim to know them all. Here are some arguments why I think it'd be reasonable to assume that /bin/sh is bash on openSUSE: 1. patterns-base-minimal_base depends on bash, and the /bin/sh symlink is a non-configurable part of the "bash" package. 2. we could handle /bin/sh via /etc/alternatives, but we don't. 3. our Wiki suggests testing failing scriplets using "bash -xv" (https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets) 4. /bin/sh has pointed to bash for a long time (not sure how long exactly). FTR, Fedora basically guarantees (sh == bash) for the purpose of rpm scriptlets (https://fedoraproject.org/wiki/Packaging:Scriptlets). So Fedora <-> openSUSE portability may also be an issue to consider. If we can't assume that /bin/sh is bash, what else can we assume? I recall from earlier work that writing really 100% compatible shell code for all kinds of environments is really hard. E.g., "[" isn't 100% portable either, even though it's part of the POSIX "test" standard (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html). We should have clear rules which syntax expressions can be used in rpm scriptlets, and which can't. IMO we should define one of the various existing shells as a reference by saying "if it's supported by this shell, it's valid scriptlet code". That'd be easier (especially for testing compliance) than referring to a spec. That reference shell doesn't have to be bash, of course. Thanks Martin (*) For example: # ln -s /usr/bin/echo '/usr/bin/[[' # ls -l /bin/sh lrwxrwxrwx 1 root root 4 Feb 8 10:38 /bin/sh -> bash # /bin/sh --posix -c '[[ 2 = 1 ]] && echo yes' # dash -c '[[ 2 = 1 ]] && echo yes' 2 -eq 1 ]] yes -- Dr. Martin Wilck <mwilck(a)suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (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 months

[opensuse-factory] openSUSE:Factory git mirror update

by Bernhard M. Wiedemann

Hi, our experimental git mirror of openSUSE:Factory got a new feature: It now makes single commits from most individual updates with some useful info in the commit message. This makes the whole history much nicer to read: https://github.com/bmwiedemann/openSUSE/commits/master In the usual case of SRs it links back to the SR on OBS, because that is where most of the discussion might have happened: https://github.com/bmwiedemann/openSUSE/commit/d1afc9699 but sometimes direct commits happen and they are shown with the commit message and a link to the OBS change https://github.com/bmwiedemann/openSUSE/commit/b2786e5c8 Ideas for future work: In theory we could also track these packages' devel projects on a 'devel' branch In a similar fashion we could also track openSUSE:Leap:15.* on stable/leap15_N branches to allow offline diff We could try to enable osc build to work from such git dirs. Either this uses the OBS server-side logic to resolve dependencies to get the usual .osc/_buildinfo* and .osc/_buildconfig* files or we re-implement or re-use OBS server logic to allow builds when offline. And then (in the foggy far future) it would be possible to make a gateway back from github pull-requests or gitlab merge-requests to submitting SRs in OBS. Or we re-think how OBS handles its source files until then. See https://www.youtube.com/watch?v=iY_ADUQiiQI&t=787 Ciao Bernhard M.

7 months, 2 weeks

[opensuse-factory] Too many packages to process

by Vojtěch Zeisek

I'm not sure, if this is bug or feature... After few days, update applet (TW, KDE) says there are 6843 new updates (TeX, R, ... ;-). When I click to "Install updates" error "Too many packages to process (6843/5200)" appears. Zypper handles it well. Is it worth of bug report? To b.o.o? Yours, V. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/

1 year, 2 months

[opensuse-factory] Python 3.8.x blocks 3.7.x updates

by Michael Ströder

HI! Tumbleweed still ships Python 3.7.3 while 3.7.6 was just released. devel:languages:python:Factory/python3 is already 3.8.0 but I guess this cannot be submitted to Factory until all the 3.8 issues in third-party modules are solved. (BTW: 3.8.1 released yesterday.) Until that happens I'd vote for doing updates to 3.7.6 and submit those to Factory to get it into Tumbleweed. Opinions? Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 3 months

[opensuse-factory] Default browser: chromium?

by Tomas Chvatal

Hi, Let the flamewar begin! No really I was now watching the people rightfully complaining I've sent a borked chromium to latest TW snapshot and was wondering how popular the browsers are and whether we should not set the chromium instead of firefox as default or to keep them both on the dvd tested... In order to even start some process lets all vote in a poll for what is your default browser between the two (yes yes you can use the Vivaldi or even w3m, but honestly the chromium or ff are the two used by the majority of the people around). So if I could get you to vote in my lovely poll: https://doodle.com/poll/nnn53kkryghdvc84 I will make the results hidden so people won't start to game the system too much and the results will be announced here at the beginning of the October. Cheers Tom

2 years, 4 months

[opensuse-factory] Default Java

by Bernd Ritter

Hi there, just wanted to let you guysome days ago I wondered what the default java version would be. It should be Java 11. So I've installed a clean leap beta installation. I've installed java-openjdk-10, java-openjdk-11, java-openjdk-1_8_0. Same with the equivalent devel packages. The default java version is Java 11 both with "java" and "javac" via update-alternatives. So everything's fine. I've updated the wiki page accordingly (https://en.opensuse.org/Features_15.1#Java). Does anyone know why there is no Apache Maven available in the default packages? There is this "maven-local", which I think is not the maven program itself. Cheers, Bernd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 4 months

[opensuse-factory] High Xorg CPU usage with latest updates

by Karl Ove Hufthammer

With the latest Tumbleweed updates, /usr/bin/X seems to use ~40% of my CPU, causing(?) the whole system to become quite unresponsive. More specifically, the system seems to freeze (very briefly) several times a second, making both mouse and keyboard input and video playback rather jerky. I hadn’t updated Tumbleweed for about a week (before updating yesterday), so I’m not sure exactly which snapshot introduced the change. I didn’t find anything relevant on Bugzilla, and unfortunately, I had just deleted earlier snapshots, so I can’t do a rollback to debug further. But changing the graphics card driver from the proprietary NVIDIA driver to Nouveau fixed the problem (CPU use back to normal, i.e. about 2%, and the system is responsive). And then changing back to the NVIDIA driver again reintroduced the problem, so it might be caused by the latest NVIDIA drivers *or* something else related to graphics. Have anybody else experienced this problem, or have some tips for debugging it? -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 4 months

[opensuse-factory] Heads up: bluez-package will get rid of the deprecated binaries.

by Stefan Seyfried

Hi all, I want to announce a small change in the bluez package: some time from now, it will be built without the "--enable-deprecated" configure switch. This switch causes the old deprecated (by upstream) tools to be built. Right now, they are built and pacakged in the bluez package. The first step will be to split them off into a "bluez-deprecated" package, which contains the following binaries: /usr/bin/ciptool /usr/bin/gatttool /usr/bin/hciattach /usr/bin/hciconfig /usr/bin/hcidump /usr/bin/hcitool /usr/bin/rfcomm /usr/bin/sdptool In the not too far future, the bluez-deprecated package will be dropped and bluez will be built without "--enable-deprecated". If I had to guess now, I would say that "not too far future" means "end of 2020". Why do this? These tools are officially abandoned and deprecated by upstream, and issues, even security problems have to be fixed. Upstream does no longer maintain or fix bugs / issues in these tools. If you have a problem with these tools going away, *please raise these issues with bluez upstream*. The bluez / bluez-deprecated split will take place with the next factory submission. -- 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 years, 4 months

[opensuse-factory] Trying to find which change is causing segfaults.

by Konstantin Voinov

Hi, I need the advice how to localize a problem which appeared few snapshots ago. Sadly, I didn't catch it in time. What we have: VST Plugins that I compile locally and in OBS https://build.opensuse.org/project/show/home:kill_it:JUCE TW 20191221 on AMD FX-8120 (Kernel 5.3.8-1.2 glibc 2.30-1.2) TW 20191106 on i5-2410M (Kernel 5.3.12-2.2 glibc 2.30-2.1) On the first machine most of these plugins *.so crashes in some hosts with segmentation fault, but can be loaded in others (why I missed the case). On the second - everything works without problem. It doesn't matter either vst from OBS or built locally or even from Leap repo, result is same. So I guess the cause somewhere in libc or kernel (or maybe smwhr else). Before posting bugreports (to our bugzilla or to plugin/framework devs) it has to be definitely known where to dig, I think. Thanks for any help. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 4 months

[opensuse-factory] Grub2 error during grub2 update

by Bjoern Voigt

The last snapshot 20191228 again updated Grub2. My problem is, that the %posttrans script 'grub2-i386-pc-2.04-3.2.noarch.rpm' fails. /usr/sbin/grub2-install --target=x86_64-efi Installing for x86_64-efi platform. Could not prepare Boot variable: No space left on device /usr/sbin/grub2-install: error: efibootmgr failed to register the boot entry: Input/output error. Many users from different distributions had this problem too. The error message "No space left on device" is misleading. The real problem is, that there is a problem with the UEFI variables. Some users suggest to remove "dump" variables, but I have no such variable. # ls /sys/firmware/efi/efivars/ | grep dump # ls /sys/firmware/efi/efivars/ | wc -l 85 (source https://unix.stackexchange.com/questions/379774/grub-installation-failed) My work-around was to copy the new Grub2 EFI boot code. My PC boots with this change. # efibootmgr -v Timeout: 1 seconds BootOrder: 0002,0000,0001,0004,0007,0008 Boot0000* CD/DVD Drive BBS(CDROM,,0x0) Boot0001* Hard Drive BBS(HD,,0x0) Boot0002* Windows Boot Manager HD(1,GPT,a4b17afc-3db4-47b8-980f-bb3cec43d8c7,0x1a9c3800,0x64000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...I_............... Boot0004* UEFI: Samsung SSD 840 EVO 250GB PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/HD(1,GPT,a4b17afc-3db4-47b8-980f-bb3cec43d8c7,0x1a9c3800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI) Boot0005 CD/DVD Drive BBS(CDROM,,0x0)P2: HL-DT-ST DVDRAM GH22NS50 . Boot0007* Windows Boot Manager HD(2,GPT,60cdbfb7-e8c8-4820-aeb3-1dc2f9572921,0x96800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...d................ Boot0008* UEFI: Samsung SSD 840 EVO 250GB PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/HD(1,GPT,a4b17afc-3db4-47b8-980f-bb3cec43d8c7,0x1a9c3800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI) Boot0009 Hard Drive BBS(HD,,0x0)P0: Samsung SSD 840 EVO 250GB . My UEFI (Intel DH55TC mainboard, TCIBX10H.86A.0048.2011.1206.1342 from 12/06/2011, no updates available) is old and buggy. But what else could I try? My fear is, that one of the next Grub2 or Windows 10 updates will break the boot process. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 4 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory December 2019