openSUSE Factory September 2020

factory@lists.opensuse.org

81 participants
82 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

1 month, 4 weeks

[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] new package: irqstat

by Dario Faggioli

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)

1 year, 1 month

[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] Convert from classic to transactional server?

by seroton10＠gmail.com

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

1 year, 2 months

[opensuse-factory] openSUSE reproducible builds status 2020-08

by Bernhard M. Wiedemann

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.

1 year, 5 months

[opensuse-factory] [RFC] OpenSUSE Distribution Tiers Policy

by Dirk Müller

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

1 year, 5 months

[opensuse-factory] Thunderbird 78 and encryption status

by Wolfgang Rosenauer

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

1 year, 6 months

[opensuse-factory] [CtLG] questioning usage of qemu/SDL2 in openSUSE Leap

by Lubos Kocman

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

1 year, 7 months

[opensuse-factory] xauth and now gone ~/.Xauthority

by Hans-Peter Jansen

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

1 year, 7 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 September 2020