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
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.
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/
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
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
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
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
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
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
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