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.
Hello everyone,
There's a new package in server:monitoring called `irqstat`, which I'd
like to get into Factory:
https://build.opensuse.org/package/show/server:monitoring/irqstat
It's a rather simple, but yet quite effective, python script for both
online monitoring and offline parsing of the content of the special
file /proc/interrupts.
In fact, especially on large servers, where that file may have
something like 550 lines and 224 columns (this is a real example, I'm
not making numbers up :-) ), it may be very annoying to tell, e.g., how
many IRQs a particular source is sending toward which CPUs using only
the usual tools. And this is exactly where irqstat helps.
There is more that can be done, and in fact, I'm also involved with
upstream development (yes, for the ones that I've seen the other
thread, I eventually did manage to get in touch with the maintainer!)
and have some plans. E.g., improving the documentation is quite high in
my TODO list for the project.
I'd be interested in any feedback, comment, question, whatever. :-)
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)
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,
When installing openSUSE (any flavour), the installer offers a choice
between the "server" and "transactional server" roles, among others.
If I choose to install using the "server" role, is there a (supported)
procedure by which I can later convert it into a "transactional
server"? (Assume using btrfs for /, and having snapshots.)
I tried to do this conversion on a test system running openSUSE Leap
15.2 as follows:
* run "zypper install patterns-base-transactional_base"
* edit /etc/fstab to make root read-only
* reboot
This appears to work: The system self-updates, and reboots when needed;
/etc has been turned into an overlay filesystem; and zypper up tells me
to use the transactional-update tool.
However, one of the packages installed during the conversion is "read-
only-root-fs", and its description contains a rather stern warning:
Files, scripts and directories to run the system with a
read-only root filesystem with /etc writeable via overlayfs.
This package should never be installed in an already running
system! It should only be selected by a system role for a
read-only root filesystem with transactional updates.
The package will create / modify entries for mounting /etc and /var.
Those entries are used by dracut to mount the overlay file systems
during the early boot phase.
After reading this, I ask myself, was it just dumb luck that the test
system wasn't destroyed during the conversion? What can/does go wrong
if read-only-root-fs is installed in an already running system, against
the advice given?
Any clarification on this would be much appreciated.
Regards,
Olav
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi,
last month's status:
https://lists.opensuse.org/opensuse-factory/2020-07/msg00417.html
Last months' reproducible builds project updates (including my work):
https://reproducible-builds.org/reports/2020-07/
I uploaded https://rb.zq1.de/compare.factory-20200830/ today
and rbstats are:
total-packages: 13244 (+111)
build-tried: 13236 (+110)
build-failed: 66 (+28)
build-n-a: 125 (-1)
build-succeeded: 13045 (+83)
build-official-failed+na: 323 (+72)
build-compare-failed: 431 (-3)
build-compare-succeeded: 12614 (+86)
verify-failed: 519 (+28)
verified-semi-reproducible: 12362 (+258)
verified-bit-identical: 0 (+0)
bit-by-bit-identical: 12488 (+106)
not-bit-by-bit-identical: 558 (-23)
https://rb.zq1.de/compare.factory-20200830/graph.png
shows the change over time
https://rb.zq1.de/compare.factory-20200830/unreproduciblerings.txt
lists very unreproducible core packages (bootstrap+DVD)
Of the badly unreproducible packages,
2 were in ring0
45 were in ring1
That makes it 47/3268 => 1.44 %
which is below the overall average of
431/13045 => 3.30 %
558/13045 => 4.28 % of packages are not perfectly reproducible
Build workers were upgraded to Leap-15.2 to have a rpm that understands
zstd.
Several small packages seem to build faster now, possibly because the
setup of the build environment is faster with zstd.
E.g. "hub" went from 181+139s to 87+64s for -j1 and -j4 builds
and "xinit" went from 64+63s to 46+51s
Notable unreproducible core packages:
cargo-c:
parallelism? + filesys in rust libgit2-sys
installation-images:
ordering issues and plenty other issues
xen:
PE timestamps in .efi files
Ciao
Bernhard M.
Hi all,
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
This is a draft aiming to define what a Premium Tier openSUSE
Distribution architecture is. Currently this is mostly x86_64 as it
stands today out of historic reasons, and rather than letting historic
reasons define the future, I'd like to make it a bit more transparent
on why that is and what quality standards an openSUSE distribution has
to offer for other architectures to be considered also a main /
premium Tier openSUSE Distribution.
Please be aware that this does not silently introduce aarch64 as a
premium tier, however it is aimed to define the rules that any
architecture port including aarch64 would have to meet in order to be
considered a premium tier. So once we agree on the terms and scope,
AArch64 would be requested to be evaluated against this.
For the interest of tracking, please refrain from editing the main
page, and use either the mailing list discussion here or the Talk page
for comments/questions/considerations/feedback.
Thanks!
Dirk
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi,
since there have been multiple threads on different lists about
availability of Thunderbird 78 for openSUSE please let me share the
latest news.
Upstream released Thunderbird 78.2.2 last week. Upstream did not enable
automatic updates to 78 from 68 and also recommended to distros to not
upgrade until now. It's likely that this changes with 78.2.2 being
released now.
The main reason is that there was no finished PGP support in TB 78.
Previously it was provided by enigmail but as TB 78 does only allow
webextensions enigmail cannot work anymore to provide PGP support.
Therefore upstream implemented their own OpenPGP support natively in
Thunderbird 78 which has been finally enabled by default in recent versions.
You can find the upstream FAQ here and if you are using Thunderbird with
enigmal today you really should read it carefully:
https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq
So what about the current status for openSUSE:
The "mozilla" OBS repository (which is for ages the official project you
get current versions as backports to supported openSUSE distros)
currently contains
Thunderbird 78.2.2
enigmail 2.2.2 (which requires 78.2.2)
(please find its purpose in the FAQ above)
how those will soon be submitted to Tumbleweed.
When this "soon" will be depends a bit on your feedback if there are
still major issues found during the next days. So please feel free to
provide feedback on the list, in bugzilla, or directly to me.
After Tumbleweed I'm quite sure that the SUSE guys will also move along
putting the version into supported Leap versions.
Wolfgang
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hello team,
Virtualization team for SUSE Linux Enterprise is in favor of not
brining back SDL2 support for qemu as it was previously dropped in
favor of GTK. This means that openSUSE jump will not have qemu-ui-sdl
unless we fork and rebuild the package.
Are you aware of any usecases, that would justify additional
maintenance of qemu-ui-sdl in Leap so we could bring it back to the
project?
Please let me know by end of the week.
Thank you
--
Best regards
Luboš Kocman
Release Manager openSUSE Leap
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nuremberg
Germany
(HRB 36809, AG Nürnberg)
Managing Director: Felix Imendörffer
Hi,
what's the canonical way to run scripts (eg. from crontab), that want to
access the X session, (eg. xprop, wmctrl), now that xauth is a random file in
/run/user/$UID?
Before the switch, it was possible to run such scripts from crontab, using the
pattern:
XAUTHORITY=~/.Xauthority DISPLAY=:0 ~/bin/script
Cheers,
Pete
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org